build: simplify iOS and Android build configuration

[13rac1]

Implements iOS support to enable side-by-side installation of debug and production builds. This allows developers to run both versions on the same device without conflicts.

Removes flavor complexity from both platforms. Previously, both iOS and Android required --flavor flags for all builds. Now standard Debug/Release build types handle dev/production differentiation automatically.

This is an upgrade from #189

Fixes flutter run on iOS:

$ flutter run
...
Launching lib/main.dart on iPhone 17 in debug mode...

Error: The Xcode project does not define custom schemes. You cannot use the --flavor option.

Changes:

• Remove Android productFlavors, use applicationIdSuffix on debug buildType
• Remove iOS custom build configurations (Debug-dev, Release-production, etc.)
• Use standard Debug/Profile/Release configurations for iOS
• Create Debug.xcconfig with dev bundle ID and display name
• Update Release.xcconfig and Profile.xcconfig with production settings
• Remove default-flavor from pubspec.yaml
• Update Makefile, GitHub Actions, and Fastlane (remove --flavor flags)
• Fix deprecated flutter format -> dart format in Makefile
• Fix deprecated Swift syntax in AppDelegate.swift
• Set iOS minimum deployment target to 14.0

Benefits:

• flutter run just works on both platforms (no flags needed)
• Debug builds = dev (bundle ID with .dev suffix)
• Release builds = production (standard bundle ID)
• Side-by-side installation still works via different bundle IDs
• Simpler build system, easier for contributors to understand

Usage:

  flutter run              # debug/dev build
  flutter run --release    # release/production build
  flutter build apk        # release APK
  flutter build ios        # release iOS

[kolaente]

I've tried building this with flutter run but could not get it to work:

Error (Xcode): lstat(/Users/konrad/www/vikunja/app/ios/Flutter/Debug.xcconfig): No such file or directory (2)


Could not build the application for the simulator.
Error launching application on iPhone 16 Plus.

Same when explicitly passing --flavor dev

But I've never done iOS development before, not sure if I set it up correctly?

[13rac1]

I've thought through this further. Do you/we need the build flavors? As far as I can tell, they are not necessary. I've got a working build of Android and iOS without the flavors.

[leschbenedikt]

I don't think we need flavors.
Currently they are used as build types.
As I know it flavors are typically used for different feature sets like pro and non-pro or something like that.

[13rac1]

Alright, I forced pushed a completely different implementation simplifying both iOS and Android. @kolaente and @leschbenedikt what do you think? Does this work for you? No flavors at all.

• flutter run → defaults to debug (for development with hot reload)
• flutter build → defaults to release (for distribution)

[kolaente]

I think we've originally introduced the flavours because there was some problem when building without them. As long as it works now I'm fine with removing them.

@leschbenedikt what do you think?

[leschbenedikt]

Most of it looks good to me.

I don't know much about ios development but what I don't understand is why the scheme was renamed in the fastfile from "Runner" to "production"?

[13rac1]

@leschbenedikt

Oops! Fixed, it is supposed to be Runner and is now.

[leschbenedikt]

Thanks.
I think the bundle identifier should be "io.vikunja.app" instead "io.vikunja.flutteringVikunja" like in the android app.
Also not completely sure about this one

[13rac1]

I prefer io.vikunja.app too, but it was already set to io.vikunja.flutteringVikunja. Happy to change it if there is no official iOS build/release/etc yet. There is https://apps.apple.com/us/app/vikunja/id6751271029 which according to https://itunes.apple.com/lookup?id=6751271029&country=us has bundle id of de.nlmyr.Vikunja

[kolaente]

Yeah, the app id should be io.vikunja.app. The flutteringVikunja id was a leftover from a previous attempt.

The app in the app store that you mentioned is not associated with the Vikunja project.