I am trying to figure out what would be a good way of setting up application architecture and how to setup Xcode project itself, in the case where I have one base application, and I need to make multiple applications of it where the all apps will have those same base functionalities but will differ in a way that:
Assets may be different
Some features can be added ( new screens that uses new endpoints that are not defined in base app)
Localization can be differ (eg. one app can only be translated to english, and other can support multilanguages)
and probably some more, but you get an idea of what kind of an app (kinda template app) I am referring to.
What would be a preferred way to implement something like this? I guess targets and making a framework for a shared code is one way to go? Or there is something else that would be suitable too?
Target is a good start. Thanks to target memberships, you can "share" storyboards, source files and whatever you want between several targets. Then within each specific target, you add your assets and specific functionalities.
Frameworks can be also a good way to share functionalities between apps. But you can start and try simply with targets, and then later factorize code within frameworks.
The way I would do it could be this way :
Create your project with a single target, let's call it "Blank App"
Develop functionalities and prepare generic assets for this app
When you want to add a new App, duplicate the "Blank App" target, remove membership of default assets, add new ones, add also specific source and resource files, and that's it.
After a few targets, you can spot what can be factorized within frameworks. Add a new framework target, migrate your sources in it, make all apps use this framework, and you'll have a nice system.
Related
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.
Android has very good tools for creating different variants of an app (for example, the exact same code but with a different logo). You just create a different flavour and put a different image for each flavour's directory. How do I achieve this in Xcode? The information I have found on the web is very bad. I tried creating a new target for my project but that created a new storyboard, AppDelegate etc. It just created a new app altogether. I want different resource folders for different brands of the app. I'm using Swift.
You're not likely to get the same kind of setup you could have with Android. There are a bunch of features you could use individually or in combination. rmaddy's comments are good. Another option is creating additional schemes and setting the properties of the project for each one. The important thing to keep in mind is that the simplest solution may not look the way you're expecting.
I have a iOs app that should change its style and logos in function of which company ask us for the app.
What I want is, have different configurations for the same app, so I can put a folder there with the personalization, create a new configuration, and compile it(In android we use flavors, In web we use .css folder, so it is easy to make a new version).
I think that you can achieve this with Targets, schemes and build configurations but I cant figure out how this exactly work as I cant find a good example of what I want
I want to make multiple apps which share the same structure and code, but have different images, fonts, names and urls.
I would like a simple way to make this apps without replicating the whole project, so that when I find a bug I'll have to correct it only once.
Thank you.
PS: It isn't important the language (Objective-C or Swift)
Create multiple targets within the same project. You can then include or exclude asset catalogues, configuration JSON files etc. on a per-target basis. If you're consistent with the names this should get you most of the way there. You can also look at target-specific build flags or constants.
I'm doing a series of book apps for a client. There's a lot of books in the series, and each one will be a separate app. Instead of making changes to all the apps every time they want something tweaked in all of them, like the position of a button or something, I'd like to make a universal "framework" (library?) that I can import to a project, just as I would do for one of the iOS SDK's frameworks. The framework would have all the universal components of the apps, which would include a controller class I would subclass in each app to do the app-specific things. Then when I need to make changes to all of them, I could just change the code in the framework, and it would affect all the apps that use it. I'd also like to be able to include common images and other media.
Do I want to use the "Cocoa Touch Static Library" template in Xcode? I also saw this project in github: https://github.com/kstenerud/iOS-Universal-Framework; would this be a better fit for what I'm trying to do?
For your purposes, the simplest approach would simply be to set it up as a static library project. Then, for each application you want to use it, drag the project into your workspace and add the static library product as a dependent target.
As far as I am aware, the current leading method for building a framework on iOS is Jeff Verkoeyen's iOS-Framework.