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.
Related
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.
I have an IOS app which holds lot of Configuration settings to use the app and also this app is used in 5 warehouses, settings will be differ from one warehouse to another warehouse. So it becomes more painful for the users using this app.. Even ever they install the app then need to set the configuration settings.
So my problem is If i hardcode the settings value, it is very difficult to maintain the code for all the different warehouse. if i do small change in my app have to change in all of the 5 source code.. Even if i decide to maintain 1 code .. i have to change the setting value every time before setting the build.. It is more painful for me.
so my question is..
Is there any way to run a app and set values in configuration settings. And generate this setting app as a build ?? i don't know it will workout or not please share me some ideas..
If I understand correctly, you want to have 1 source code and there is possibility to create different Targets. Each target can have it's own configuration plist file and you can set also different preprocessor macros for each target.
How to use preprocesor macros you can see here: How can I differentiate between multiple targets in xcode at runtime
How to create targets you can see here: Add preprocessor macro to a target in xcode 6
One more possibility (besides targets) is to create a shared library and if you want to apply some configs after installation you can prompt user to download one from a server (for instance)
Yes, you can create different schemas.
For example, you can create an application for Development, Staging, Production.
You can have configurations in plist file and make it variable according to the schemas.
When your application opens it will take the values according to the schema with which it was built.
Follow this guide to create different schemas.
Also, you can integrate Fastlane to generate builds easily with different schemas with simple commands.
Yes you can have one app with different targets and schema. Then just google it there's many articles about.
I started working at a company which developed an App for mobile payment. There is a "Terminal"-App, which receives payments of customers and then there's the "Wallet"-App, which users can download and use to pay (at those terminals).
The project consists out of 2 targets - one for the Wallet and one for the Terminal. The App is used only in 2 Countries. It's all quite sophisticated and has a huge code base.
Now I need to whitelabel the whole product for a client, who wants to use our App (both targets) with his own branding (and maybe some additional features or without some specific features) and I'm not sure what the best way would be to achieve that.
Currently I see 3 options:
Duplicate whole project
To copy the whole project to a new folder and make my changes in that new folder would probably be the most "dirty" approach. At some point, my first code base could differ from the duplicated one too much. Additionally, if any security-related issues would come up, I would have to fix it in both projects.
Create another 2 targets
I was actually thinking that this would be the best way to go. Creating a new target for the Wallet and the Terminal and then checking the current target in the source code to decide which features should be enabled or disabled sounded pretty good to me at the beginning. But then I created the new target and noticed that I will have to set that checkmark on EVERY single class for that new target. Besides that, I'm not sure any more if that's really the best way to go.
Use If-conditions
The third option would be to wrap every function, that will be available in only one of the apps, with an if loop. I see this as the "cheapest" option because it's easy to set up and I can still maintain my code base pretty well.
Is there any other option I have? Which way would yo go?
The most significant difference between the base App and the whitelabeled one will be its language. The whitelabeled version will be right to left, but iOS does a pretty good job on that without needing me to do all the mirroring.
You definitely want the extra targets. Having a new target means it's easy to use a separate bundle identifier, signing settings and more. It might seem like a pain to have to tick a bunch of boxes to add your files to the new target (perhaps quicker to use the target's Build Phase|Compile Sources list in Xcode) but it's worth it to create a real separation between the apps.
Instead of using a bunch of source code checks to determine which white label app you're in, consider making your app more data-driven. A plist file could be used to determine which capabilities your app has, and a different plist file can be used for each target.
For example, it might contain a top-level dictionary called features, with true/false values for a bunch of feature names. You have a FeatureManager that reads the file and is the single source of truth for all app components that want to know if something should be available or not.
I'm developing an iOS app with Swift 2 and, like most developers, I have a staging and a production environment, with different servers, URL and settings.
I'm looking for a way to quickly switch between the two configurations as I'm developing the app.
On Android I could use build types and flavors to solve this problem.
I've read a lot of guides around the web but all of them were in Obj-C and relied on the macro preprocessor and the #ifdef that was available in Obj-C but isn't in Swift.
There are no clear guides on how to do this in swift and, being a total beginner, I'm not even sure where to start looking.
To recap: what I'm looking for it's a way to switch between two configurations (ex 2 property list files) and to reference the settings contained in those configurations from my code, based on the build I've selected.
You can add a user defined setting in Target's settings with different values for each scheme (Debug, Release, Ad-Hoc, AppStore etc) and use the user defined variable in info.plist file (or as you call it configurations).
Check answer to this question. Although the question is specific to Facebook App Id setup, the answer applies to any generic setting.
Once you have correct data in info.plist you can directly use it in code.
In my iOS App, i want two separate teams for Crashlytics reporting. One for internal testing and other for client team. During Development, if crashes will come then it should report in dev-team and if app will be live then crashes should be report in client-team. dev-team and client-team can have common members. How can i achieve this behaviour.
According to mine, if i create two organisations and register my app in two organisations and just switch the API keys in the app when i needed; I think it can be the solution for it. Need your suggestion/solution; Many thanks.
If any other solution exists for this problem then your direction will be more anticipated.
Since Crashlytics differentiates apps using the bundle ID, you can just change that. In order to make your bundle ID dynamic, go to your info.plist file for your project and change the Bundle Identifier key to the value:
com.yourcompany.${CUSTOM_BUNDLE_ID}
Then in your build settings, add a user-defined key called (you guessed it):
CUSTOM_BUNDLE_ID
And then you can specify a different setting for debug, release, distribution:
This will let Crashlytics register different "apps" for the same binary.
To make things even easier, use the same approach to specify a custom product name so that apps will appear with different names and devs/qa can easily identify what "version" of an app they're testing.
We generally don't upload our dev binaries to Crashlytics because we build so many times and we QA on builds from our CI server. That's why we actually specify the product name and bundle ID dynamically at build time on our CI server. This allows (for bigger projects) many parallel apps with different bundle IDs to be distributed/tracked by Crashlytics and all it takes is a new build config.