one code base for iphone generic application? - iphone

I have built a generic application which can handle different content data - but for each content data, it will be a different iphone application (with a different name).
I would like of couse to only keep one code base for all these different apps (as it would be easier maintenance) but I have 2 questions:
1- I would need to change the appname in the buildsettings, etc.. and may be it is going to be an overkill...? especially with the upload process then...? What are your experiences in that domain and what would you recommend me to do?
2- how can I have all the pictures for logo (Icon.png, etc...) to co-exist into one app? For the moment, I have a global variable (as a singleton pattern) that I switch to change appname and loaded data inside the program
Thanks in advance for your help
Cheers,
geebee

You can do this pretty easily, it's what most developers do in their lite versions. All you have to do is add another target to create a new app out of the same code and use that global variable.
In order to change the images included in the app you simply edit the target and under the copy bundle resources menu remove the unnecessary resources. You'll notice that when you add a new resource you have the option to include it in any one or more of your targets. Simply select the one that you want and it will only be accessible to that target.
The reason that this works is that each target can have its very own info.plist. All the settings and resources can be separate, and the code can be different using your #ifdef global_var.
Here's a slightly outdated tutorial that should get you started if you need it.
http://www.bit-101.com/blog/?p=2098

For each application name add one target.
Create one xyz-info.plist for each of the target. (in this case for the xyz.app)
In each of the xyz-info.plist assign the appropriate icon files etc.
Within your build phases for each of the targets you will define which images go with which app.

Related

Cocoapod library and multiples configurations embedding

After googling a lot regarding my need, I finally ask to this awesome community a way to achieve my goal.
I need to create a swift library with cocoapod, and integrate multiple build configurations. I want to create 3 schemes on my project to switch easily environments variables (like target API, log level, and many more).
I really want to do this on library side, not on app-side, since it's for debug & testing purposes, and finally, applications which embed this pod will only use the "Release" build (except us, developers who maintain this library)
I tried opening the _Pods.xcodeproj and doing update in this file (create *.xcconfig files I need, mapped to configurations schemes) but disappear after ran a "pod install".
Not sure at all if you can do that hack on library side. Looks weird.
But the best practice would be:
When initializing and configuring libraries, endpoints etc (all you need to change between schemes), just check which one is used, and pass different parameters
create a file, FE Constants
struct Constants {
static var libraryApiKey: String {
#if DEBUG
return "debugKey"
#else
return "productionKey"
}
And when initializing
Library.initialize(withKey: Constants.libraryApiKey)

Create an App within an App

I am being presented with a very interesting project. The task that I must complete is to figure out a way to allow a partner to be involved in an app without giving up their source code. The code will be included in the main bundle of the app so it is not dynamically stored. The partner has a fully functional app that is needed to be ran in a window within the main app at the appropriate time. I know having the partners create a web app would be ideal so it is treated like a webpage but I am more concerned with codes that must be written natively in iOS.
My question is what is the best way to go about solving this? In theory it is like an App within an App. Is there a way if they gave up their .app file I can include this in the bundle and then run it when I catch a certain event? Should I have the partners create their code in a framework and then import into the shell project? What is the best way to approach this problem?
If your 2nd-party doesn't want to provide you with the source code, why doesn't he compile it to object code then let you simply link it to your app?
By the way, at least on official (non-jailbroken) iDevices, apps can't 'embed' or 'open' one another in such a way - you can open an app programmatically if 1. it's a separate app 2. it has a registered special URL associated to its bundle.
Is there a way if they gave up their .app file I can include this in
the bundle and then run it when I catch a certain event?
No, you'll want to have them create a library instead. You can then include that library in your project.
Creating a library is as simple as:
Choose File->New...->Project... in Xcode.
Select the "Cocoa Touch Static Library" project template.
Add your code.
Build.
The result is a static library that you can add to your application(s). The library will contain the compiled code that you added, but doesn't include the source code. The library developer should provide whatever header files are necessary to use the code in the library.
An App within an App is possible however it requires a common data framework that allows one app to reference the same data without confusing the the source of and destination of the data.
Such a framework allows one app to interact with another app referencing the same data.

Maintaining different URLs for different Build Configurations in xcode

I created four different build configurations to my xcode project, they are QA, STAGING< UAT<& PRODUCTION. I use 4 different urls each for one build i created.
Now my question is xcode 4 is very good at detecting DEBUG mode as there is already predefined macro available, but How can I detect my custom builds so that i can pass different urls for different builds configurations?
In each one of those build configurations go into build settings and add a #define THIS_IS_QA=1 then test for it in your code and use it as you would use the DEBUG macro
The preprocessor macro route works alright and is quick to implement. But it does not scale well since you will end up with copies of each variable. The route I find works the best is to do the following.
Define the configuration as a User-Defined Setting in the project or target build settings.
Doing this allows for different values to be specified for each build configuration (eg. Debug or Release or even a custom one)
Create an information property in the projects plist file.
This allows the build setting to be accessed through the plist.
Write the code once to load the value form the plist file.
Example:
In the project create a User-Defined Setting called "BASE_API_URL" and set the debug configuration to "http://www.test.example.com" and the release configuration to "http://www.example.com".
Then in the plist create a new information property with the key of "BaseAPIUrl" and the value of "$(BASE_API_URL)"
Lastly in the app delegate where you define the base url add the following code:
let baseUrl: NSString = NSBundle.mainBundle().infoDictionary?["BaseAPIUrl"]! as NSString

Equivalent to R in iOS

In android we have the R class that stands for Resources, where we have references to all of our resources and we can easily access them in the code. Is there an equivalent in iOS? I have this doubt because, I want to be able to define multiple files with different values, for instance:
DefaultValuesForViewController1
DefaultValuesForViewController2
Besides creating plist, is there another way (faster and easier like R)?
There is no R class equivalent access method.
In Android, the R class represents access to resources that are consolidated into a native format. iPhone does not do this. Instead, resource files are just copied as is into the application bundle and must be found & opened as such.
You could create a class to store all of your data for the app. iOS generally likes the app to run lean and mean, so only storing your objects for as long as you need them, releasing them as soon as you are done with them. If you were to store everything globally, it would add some overhead, but assuming you don't have a ton of information, it shouldn't be an issue.
There is no equivalent for this in iOS apps. All you get is files that you can enumerate using standard file I/O.
However, you can emulate it partially. Here's a simple demo on GitHub
You can find that SwiftGen(e.g. Tuist used it) can be used as an alternative for autogenerated R.java file on Android
Two point
it is third party source
you have to manually run script after changing your resources

How can I configure my iPhone project to use a seperate application icon for beta releases

What I am trying to achieve is for the application icon to be different in builds that I send out to my beta testers, to that of the application that will be submitted for approval. This will allow me and my beta testers to easily identify the app is a beta version.
I was not sure if I should be adding a build script to modify the info.plist and change the application icon specified there. For this I guess I would have to conditional check the build type (DEBUG/RELEASE/DISTRIBUTION etc) and write the appropriate value to the plist file.
Alternatively I thought I might need to create a separate target for beta releases and specify the new BETA application icon there.
If anyone has done this kind of procedure before, any tips and ideas about how best to do it would be very much appreciated.
Outdated: As of September 2017, my answer is probably outdated now. Please use latest Apple developer guides relating to Asset Catalogs. Asset Catalogs are the new way of specifying image/icon resources for your app.
Original answer:
Both ways you have mentioned can be used for this purpose (Through a separate Target or using Build settings). In my opinion, the more logical way would be to use a different build configuration and set the plist file to dynamically get the icon file name from the build configuration.
Here is how I would do it:
In project build settings, create a new user-defined variable called ICON_FILE (for "All Configurations")
Set the value of the variable to "Icon.png" (for "All Configurations")
Create a new build Configuration called "Beta".
Set the value of the ICON_FILE variable to "Icon-beta.png" for "Beta" configuration.
(this will make all the configurations have the value "Icon.png" except Beta config)
In the Info.plist set the value of "Icon file" attribute to ${ICON_FILE}. This will make the info.plist dynamically get the filename from the variable you defined earlier.
In your application resources, include the beta icon with the name "Icon-beta.png" in addition to "Icon.png" you already have.
If you build the app using "Beta" config, the app will have the beta icon as the app icon.
Hope this helps!
Asset catalogs can be used without creating another target.
Here are the steps I use:
1 - Create two (or more) app icon set in images.xcassets
2 - Create another configuration from project settings
3 - Go to Target -> Build Settings and search for app icon.
You will see Asset Catalog App Icon Set Name under Asset Catalog Compiler - Options. Change the asset catalog name that will be used in new configuration.
4 - Build for different configurations.
The accepted answer is not working for xcassets.
So, if you already started to use xcassets catalog here is the steps:
You need to create 2 different targets of your application.
To do this:
Right click on your target. -> Click Duplicate (or Cmd+D)
Set name of new target like MyApp-beta
Create separate icon:
Go to your xcasset catalog.
Right click on column with list of images -> click New App Icon
Name it like icon-beta, add place here your beta icons
Click on your beta-target
Go to tab General -> App Icons -> select your asset icon-beta
Here it is. Now you can build your beta application!
Another advantage of this method over that described in the accepted answer - is that you can install both versions at the same time of your Application. (you need to set different Bundle Identifier for this).