My company is building one custom B2B app which is quite similar for all clients.
The difference between the apps will be the app's name & icon and perhaps color schema.
Just to be clear - the data in the apps would be different but the layout is identical. e.g. I'd have the same button in all of the apps, but its color maybe be blue in one app and yellow in another.
I was wondering regarding how to maintain this kind of app.
The apps would be either distributed to app store or to clients' MDMs.
Considering the fact I'm going to have hundreds of apps like this - it's not possible to build & submit each of them for every bug fix I do in the app..
Any solutions out there?
If app name and icon has to be different, there is not much you can do - you need a separate binary for each client.
However there is a lot you can do in terms of automating the process, since it looks like most of the codebase is shared between apps. Just to give you an idea - you could have a script which takes some configuration (JSON, XML, etc), Xcode project and then builds and signs apps for each client with correct icon, branding, app name etc.
Essentially you maintain single code base, build tools to provision and distribute the apps and move branding and customisation to a configuration layer.
Related
Is it possible to set up iOS universal links without having a separate website?
For example, if you want a universal link that 1) opens your iOS app if the user has it installed on their device and 2) opens up the App store listing on any device without the app installed.
It seems that having a separate domain you control is the standard way to do it. The Apple documentation (here), and other guides like here and here, seem to make it pretty clear that you need to add the JSON code in the Apple App Site Association file to a separate website that you control.
But is it possible to set up universal links without that website?
Detail:
For an iOS mobile app developer, setting up a separate website, dealing with website hosting, etc. is distinct from building an iOS app, and an involved additional task to go through just for universal links. Many developers might have a site already or have experience building websites in addition to mobile apps, but it's still a different thing than building mobile apps.
So I'm surprised if Apple assumes app developers have a website ready to go for the purpose. I note there are non-Apple alternatives that do similar things that clearly don't require a website.
Edit: I am familiar with alternative linking systems, such as Firebase and Branch. I want to see how you can do it with Apple Universal Links.
So let's say you want to stick with Apple universal links. Is there a way to do it without setting up a website, dealing with hosts (and potential costs for that), etc?
If it is necessary, what would be the cheapest and easiest way to set up the bare minimum site for a mobile developer that would work for universal links?
I want to upload two build of same app with little UI changes on app store with different account. Can I upload the builds?
I have an app with multiple client so I want to upload builds for each client with their own account. I have modified the UI for each clients.
Yes, you can. What I do in similar situations is that I use one project for that (as you already have). And then I crate a copy of a target, so that I can customise it (custom logo, custom icon, ...).
To apply customisation in code I take advantage of "Custom Build Configurations". Here on SO I've described how I do this (as of writing it's the third answer to the question) custom Build Configurations
Sure you can, just make sure that the bundle identifier is different.
No issues in doing that. Just take care of the following things which must be different:
Logo
Bundle Identifier (as suggested by Fabio)
package ids of in app purchase items, if any
App preview images/videos
If you are using iAds for showing ads in your app, make sure you do not use the same provider account.
I am writing multiple apps for iPad. All these apps have some settings in common. I therefore would like to have one app that handles the settings and write them to a file - the respective apps will then retrieve their settings from this single file. Is there a way to access one file from different apps on iOS?
The iOS Keychain may help -> http://shaune.com.au/ios-keychain-sharing-data-between-apps/ though a Google search for FireMonkey APIs for the keychain has proven fruitless. At least it could be a starting point.
I have a base project, which I would like to re-brand and resell for clients. So my question is: When I branch and create a new project obviously it needs to be a separate entity from the main. Is the only thing that separates these apps during submission the Bundle ID?
Since renaming projects can sometimes be a pain, what I'm doing is:
Creating the branch
Opening it in XCode and changing the Target name, and this changes the bundle ID because it's set to com.whatever.${PRODUCT_NAME:rfc1034identifier}.
So I'm wondering when submitting a new project, is the bundle ID the only thing that needs to be globally unique? or are there more attributes that I would need to change for each new branch/project?
Thanks
From my experience, only the bundle ID needs to be different.
A few things you should notice though:
You probably want the app splash screen / icon / icon label to be different between clients too
Under Build Settings your Code Signing Entity might need to be different too. If you have certificates+provisioning profiles which are specific to the bundle ID, you would have to create new sets of those for every client and use them when building
If you see that you're starting to change resources (like the icon / images for branding / string tables) between clients, using multiple projects and a shared static library may be easier for you. Take all of your shared code and convert it to a static library iOS project, and then create a separate project per client (normal iOS app project) which uses this library. This way all the metadata (like bundle ID, certificates, icons) can be different, and the code be the same.
If your app defines any URL schemes (for example, if you implement login with Facebook you need to do this), these schemes should be different between clients too. If they are the same, you are bound to have collisions when a user installs 2 apps on their device.
And one last tip regarding Apple policy:
If you are planning to submit all of these client apps under your developer account, this may be against Apple policy and your apps might be rejected. Apple wants you to open a dev account (and pay the $99/year) per client..
I read that PhoneGap is approved by Apple as a framework for building native apps, but I'm not clear on how this does not constitute a "website wrapped as an app," something that Apple specifically doesn't like, as per their App Store guidelines. I'm assuming it is because the JS is contained in the application, rather than running on a remote server?
Any clarification on this issue would be most appreciated.
but I'm not clear on how this does not constitute a "website wrapped
as an app," something that Apple specifically doesn't like, as per
their App Store guidelines.
By this Apple means Apps that simply show a UIWebView that loads a remote website, so it basically just behaves like Mobile Safari, just without the controls. Also they wan't Apps to show at least a UI when the device is not connected to the internet, like in the Facebook App where you can still read already downloaded status updates, view photos etc. That's what a "I just wrap a remote website inside a UIWebView"-App can't do.
PhoneGap Apps have all the resources they need (HTML, CSS, JavaScript) on the device residing in the App's bundle, so using such an App would not depend on network availability and could at least show a UI that tells you to connect to the Internet in order to use the App, or they could display already loaded content (like Facebook, Twitter and so on).
I think that the signature of the binary tells Apple what framework built the application, and since all the supporting files (js included) are included in the project and therefore in the binary, it is a standalone application. That being said, I still think that doing things Natively is the best way to go. I am extremely comfortable with javascript and started out thinking Phonegap was the way to go for me. I did a couple of projects with it and then decided to take the plunge and learn Objective-C. That worked out so much better for me. No dependency on a third party framework and I wish that I had started that way.
Sometimes the easy way out just hurts ya in the end IMO.