I'm looking at Firebase documentation on how to achieve this (see here). Here is the instruction:
If the builds are part of a single target, the best option is to give both configuration files unique names (e.g. GoogleService-Info-Free.plist and GoogleService-Info-Paid.plist). Then choose at runtime which plist to load.
However, at the end of the page, there is "caveat" to this implementation:
On iOS, do not add GoogleService-Info.plist to your project if you are supplying different configuration at run time, as this can result in an apparent change of GOOGLE_APP_ID and result in lost Analytics.
Since I'm trying to add multiple environments to an existing app (live in the App Store) that has a GoogleService-Info.plist added to its project, does that mean I cannot do that since it will result in lost Analytics? Or, can I simply remove the GoogleService-Info.plist and add the environment specific ones, without any problems?
The GoogleService-Info.plist is recommended since it allows Analytics to report early events. If you configure it at run-time, says switching from Google App ID A to B, then you will lose events of A logged before configuring with B. It's more like a warning to let you know the risk of using the runtime API.
Related
I am using Google Map Service in one of my iOS apps. I have two configurations Development and Production. Google Service TRACKING_IDs are different for both of the configurations so, every time when I prepare final AppStore version I need to change the TRACKING_ID from GoogleService-info.plist which is a repetitive manual work for me. I would like to know if that TRACKING_ID can be configured from source programmatically to avoid this manual checklist. I can detect configurations using macros but I do not know how I can override the .plist stuffs for Google service.
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.
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.
I'd like to release one of my projects (an iPhone app).
The problem I have is that I use Parse, google admob and google analytics, so all of them have private keys or app keys that I have to remove when publish them as open source. But I stil want to continue the development of my app from that repo.
How can I automate the process of removing that data and at the same time add them when I work with the project? I want to avoid uploading that private data by mistake.
I'd like to know your suggestions or ideas about this topic.
BTW, I prefer to use BiitBucket or GitHub, maybe they have some feature or plugin for that, no idea.
A good practice consists in gathering all your private keys in a config file (in the case of your app it would be a header containing several define), and add this config file to the .gitignore of your project. Then in your README simply mention that contributors should create in their workspace this config file with their own private keys.
By doing this you will first have a unique config file, so you know where to look at when you want to update a key, and secondly it will prevent you from publishing it by mistake.
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.