We are planning to move our codebase to flutter, but we have some specific requirements and trying to validate them before moving all our codebase to flutter.
With same codebase we are producing multiple targets in IOS and Android (In android its called flavors). And each target has different bundleId, application icons, launch images etc...
For each target we have a scheme related with that target.
We've 4 build configurations (Debug_Development,Debug_production,Release_Development,Release_production) to compile all of our targets.
I've looked at the below examples :
https://cogitas.net/creating-flavors-of-a-flutter-app/
https://medium.com/#salvatoregiordanoo/flavoring-flutter-392aaa875f36
But both of them were about creating multiple build configurations, but they don't mention about creating multiple targets.
So my question is , is it possible to create multiple targets and multiple schemes at the same time with flutter ?
If its possible , how can we do that?
You can see our current applications scheme and target configurations in below screenshot:
Thanks
I have a Youtube tutorial series on how to do this exactly. Following that, you will be able to separate environments in dart as well as native side and you will be able to use all the features available with Android flavors and iOS schemas and build-configurations.
In the tutorial I have shown how to use two different firebase configurations for dev and production version in both iOS and Android. If you have any questions, you can comment
You can use build variants:
A flavour or a build variant can be multiple things, it can be used to
target different device architectures or different backends. Android
presents a separate distinction to both, so you can target different
Android API versions and well as different backend support, for iOS
I’m not quite certain, but it also does support these in some fashion.
and for doing this you need to modify the main.dart to support variants, here is the full article how this will work on different environments.
Related
I am reading cocoapods and I see this two lines in gradle file. Can someone explain me in details. What is the purpose of this lines?
xcodeConfigurationToNativeBuildType["CUSTOM_DEBUG"] = NativeBuildType.DEBUG
xcodeConfigurationToNativeBuildType["CUSTOM_RELEASE"] = NativeBuildType.RELEASE
By default, the iOS app has two configurations: debug and release.
You can add more configurations as shown here. Using different configurations, you can create different versions of your app: each build parameter in Xcode can have different values depending on the configuration, including user-defined.
For example, it is useful to have an AppStore configuration and a release configuration for local testing, which can use different endpoints, api keys, etc.
xcodeConfigurationToNativeBuildType lets the multiplatform kotlin plugin know which build type a particular custom configuration should be built with - the debug configuration is slower, but gives more debugging options.
iOS 12, Xcode 10.2.1, Swift 5
I've been working on two apps for the same company, one app is aimed for normal users and the other app is for agencies. Both apps share 80% of code and views (Storyboards or .nib files).
As we were on a hurry at the beginning, I created two Xcode projects and worked on each app separately. Now we're in a refactoring phase, and it's painful that whenever I wanna change something that is common, I have to change it in both projects, which means two code reviews and two new branches and two new merges into master every time.
I read about these three approaches:
Targets: But I really don't know if targets solve my problem, and how to merge the two existing projects
Workspaces: Don't know if this solves my problem, especially that each project uses CocoaPods (almost the same pods)
Building a framework: I tried this approach but using the framework in both apps and on both simulator and device was also a huge pain and I dropped it after I tried to run scripts and figure out a way to make the framework run on both simulators and devices after archiving it.
Does anyone know how to manage such thing without messing both projects?
Let's imagine - we have some SDK and a lot of released versions.
SDK includes static lib and headers, of course I can't build different versions in one project because of conflicts in class names etc...
We need to test all of them each time and purpose of testing NOT SDK itself.
I was asked to put all of released SDKs to one application and allow to switch between them.
I can create separate projects/targets and provide different ipa to install with different SDK's versions.
So my question - is that possible to create just ONE iOS project which generates iOS application to launch and switch between SDK versions to test? How?
Thanks in advance
No, you won't be able to link different versions of your SDK in the same app. 3rd party libraries and frameworks are statically linked. You can, however, create a single project that has several targets, each of which builds a version of the app with a different version of your SDK.
Your case seems like a great candidate for automated unit testing. If you build a suite of unit tests that exercise your SDK, you could easily and automatically run those tests against each version of the test app.
We have a fairly rich e-learning app, built mostly using cocos2d. Currently we are in alpha and want to setup our project structure so we can also build a Mac version to target the Mac App store. It is about 80% cocos2d with some intitial screens in UIKit which will have to be ported to Mac (re-written).
What is the recommended setup for targeting both the Mac and iOS app stores from a single code base? I assume the choices are:
Create 2 xCode projects in the same application source code root folder and use each project to build a single target. This would be: Project.xcodeproj and ProjectMac.xcodeproj
Add a new Mac target to our existing iPad application project and then fiddle with target membership to get the desired results. This would be just: Project.xcodeproj
Further complicating the situation is that we currently use cocos2d as a static library for the iOS app. We also have a library called CoreInfrastructure that has a lot of code we use across all our projects. Recently I have figured out that I can create a project to simultaneously build a framework targeting Mac and a library targeting iOS from the same code base. This is done by starting with a framework project and adding a target to build a static lib for iOS.
So just wanted to get everyone's opinion and insight. Anyone know of any caveats to watch out for in the above choices? Anyone who is building for Mac and iOS app stores simultaneously care to share their structure? Adding a target worked on our library code ... is that the way to go for the application as well?
Are there any issues doing archive and distribution builds for either choice?
Thanks in advance.
WWDC session "Sharing code between iOS and OS X" answers all the basic questions in this topic. iWork team presented how they have got away with creating Pages, Keynote and Numbers with shared code base for both iOS and OS X.
The key for their project was using:
separate Xcode targets for iOS and OS X
separate project for the shared code in a form of a .framework
target dependency on the framework from the point above
I encourage to watch the video or read the transcript from this session:
WWDC 2014 Sharing code between iOS and OS X
ASCIIWWDC transcript
I recently used kstenerud's iOS Universal Framework to build a shared framework codebase that works for both iOS and Mac apps. I just needed to manually add a target for a Cocoa framework after I had created a project for an iOS framework. That way I can develop the sharable code once in the framework and link it in both the iOS and Mac apps. You can even make the framework contain UIKit-specific code for your iOS app and AppKit-specific code for your Mac apps. I wrote about it in my blog if you are interested.
For the applications use two separate projects. Using multiple targets for iOS and Mac in one project is very useful if they are sharing a library or framework. However, in your top level application almost nothing is shared. The UIKit code will need to be totally rewritten to use AppKit, the dependencies will be different, and even most of the project settings will vary.
Of course if you really want to see everything at once you can put both platform specific application projects and all the shared dependent library/framework projects in a single workspace. This is more a question of work style. If you want to switch back and forth between the two frequently this makes the most sense. If you want to simplify what you are looking at you can put them in separate workspaces that share many of the same projects. Separate workspaces has the disadvantage that a project can only be open in one workspace at a time so you effectively can only work on one at a time.
I just use multi-platform static library targets for the shared sources. You will need to expand that to the dependencies, however. If you have platform dependent implementations, you may want to create supplemental export libraries for those symbols.
So your structure might take this form:
CoreInfrastructure - cross platform static library.
PlatShared - cross platform static library.
PlatSpecific-OS X - OS X static library (or framework).
PlatSpecific-iOS - iOS static library.
The OS X app links to CoreInfrastructure, PlatShared, PlatSpecific-OSX, Cocos for OS X, and system libs.
The iOS app links to CoreInfrastructure, PlatShared, PlatSpecific-iOS, Cocos for iOS, and sys libs.
Problem (I've found) is, there are a lot of people who have not had much/any experience developing and maintaining complex project structures in Xcode. It's a pain (IMO) to setup duplicate targets, and properly maintain them as they grow -- even when they all refer to the same source files. That's why i prefer minimal targets and proper dependency structure.
I have an existing iOS application that I need to be able to build and release multiple versions of for different clients.
This application interfaces with hardware that is available from a handful of different companies, the hardware is identical but each company sells the hardware under a different name
This is a free app, the goal is not to spam the appstore with multiple versions of the same app, the goal is to allow companies that sell rebranded hardware to have a mobile app that uses the brand name that they use for the hardware.
What I need to be able to do:
Build multiple versions of the same application that can be submitted to the Appstore, each version would be submitted under a different companies apple account. I would assume that means multiple projects so that each project can use a company specific provisioning profile
Each version has some different images (Icon, startup image, maybe a few others)
Each version has some different strings (Company name, Product Name, maybe a few others)
With Android I just create a library project and I can override strings and images with a trivial amount of effort.
With iOS I haven't found an obvious answer.
I looked into adding a new target to my existing project but I don't think that will work:
- I can't figure out how to replace images beyond the icon and starting screen
- I can't figure out how to replace strings
- Would I be able to use different provisioning profiles for the different apps that compile with the same project? I know the target settings allow different provisioning profiles, but doesn't the project settings have its own set of provisioning profiles?
Can I package the current application into a library that other projects can use and replace images/strings? So each version would have its own xCode project but use the same code.
Maybe I need to work more with the idea of multiple targets...
I am using xCode 4.2, but I am prepared to move to a newer version if necessary
Create multiple targets that use different Info.plist files. The biggest difference will be different bundle identifiers. You can also define different preprocessor macros that will control the conditional compilation of various chunks of code.
Alternatively/additionally, you can put your build configuration settings (including the changing location of the Info.plist file) into *.xcconfig files and reference those in your project, info, configurations area. Then, you can build a different version of your app by simply by changing your scheme. Putting build configration settings into files is a huge win for configuration control too.
Here's a link to setting up *.xcconfig files: http://itcoding.blogspot.com/2011/03/using-xcconfig-abandoning-build-panel.html. I've seen other articles like this as well -- but this one will get you started.
Good luck.
I did this differently at my last company, where we generated around 8 apps from one primary source repository.
We created one project that required one external class, call it Config. That class vended the unique info that makes each app unique.
Then to spin one app you create your App project, include the common "library", provide the Config.m file (Config.h is common), add the unique images etc.
This was very helpful for me. It is essentially the multi-target approach but you customize it for a company and you upload to their account.
https://developer.apple.com/videos/play/wwdc2019/304/ See from the 17 minute mark.
To summarize, you partner with the company you are developing for, from their Apple Connect account, they assign you as the developer and marketing role for the specific apps you are developing for them. You upload your builds to their account. They get ultimate decision of when they will release it and who will test it with TestFlight.