We have an iOS app that we are currently looking forward to distributing to various clients in the live environment. We have several versions of the same app (version 4, version 5 and etc). Each client wants a different version. We need to handle multiple versioning of the app. We were searching the distribution options.
Ad-Hoc Distribution
App Store
In-House Distribution
Custom Apps
Searched various options that we need to follow in order to achieve the multiple versioning requirement but didn't find a clear answer. We were checking the Custom Apps options and had a few doubts.
Will it be a problem with multiple versioning?
If we need to submit an app with a different version do we need to submit it as a new app?
We would be grateful if someone give a clear thought about how do we need to handle this multiple versioning thing in the same app.
Please note that the app name and logo will be the same in every version.
Related
We've an Application which is already live and used by many users. Now that we've came up with newer Programming language and new backend. We have created a new version of the App with completely different programming language as the older one.
We have some users who are still using the older(Legacy services).
Is it possible to create a new App with different bundleId than the older App but the same Display name and also the same Screenshots in App store as the older App?
According to App Store Review Guidelines,
Don’t create multiple Bundle IDs of the same app. If your app has different versions for specific locations, sports teams, universities, etc., consider submitting a single app and provide the variations using in-app purchase.
The problem is, we also require the older App for some of our customers, who have not migrated to the newer services.
Does Apple allows to have exactly same looking apps with different bundleIds and same display name in App Store?
Any help would be greatly appreciated.
It is possible to set this new version up as a new app, you can even use the same screenshots. What you cannot re-use is the app name displayed to your customers on the App Store (Entered in App Store Connect). That is unique and you will get an error if you try to use the same name. You can of course use the same on device name (entered in Xcode).
As long as you do not spam the App Store with "copies" of the app, there should be no problem, I've seen this countless times and there are also some prominent examples of companies "phasing" out their old apps. It would probably appropriate to remove the "old" app from sale on the store in the mid- to long-term though.
I have my enterprise application (intranet web application) released long back. I also have an iPhone app on AppStore to provide some essential web application functionalities on mobile.
This iPhone app runs against the webapis exposed by this web application and is strongly dependent on it.
I have recently released a new version of my web application which is substantially different from the previous version (technically) and is a major release.
Although it caters to the same business functionality.
When I say a major release I mean the entities, signalR version etc are totally incompatible with the previous one.
Now I have to release a mobile app similar to the one I already have on AppStore but running against the new webapis exposed by the new version of webapplication.
I have to keep on supporting Clients using both of the versions of my enterprise application and cannot have a single iPhone app catering to both due to the strong incompatibility between the two versions of the webapplication.
But going through the Apple Developer site I found below
App Store Review Guidelines
2.20 Developers "spamming" the App Store with many versions of similar apps will be removed from the iOS Developer Program
I am really confused in releasing the new app which is similar to the previous one but
Differs substantially in code base
Has a different App Icon, AppName and AppID offcourse.
Is not intended for spamming but for business continuity.
Please help me as I am clueless on this.
Note: I have already gone through all the related posts on publishing similar iOS Apps but somehow didn't receive any inputs on this specific case.
While it would be preferable from an OOP point of view - if the UI and UX of both apps are the same - to allow the app's user (or the app itself) to select the correct data provider w.r.t. your web application's version, e.g. have interchangeable implementations that yield the same results depending on the backend, your approach might not be considered 'spamming' the store.
That guideline is intended to hold back developers just changing assets and names of apps (mostly games) and release basically the same codebase 100 times, maximizing efficiency and getting promoted as 'new app' regulary.
Seeing as you already made the conceptually bad decission to develop two different apps, submit both (or seeing as the old one might already be in the store, the new one) and see what review says; there's no harm in trying.
I'm developing application for in-house distribution (so there can't be rejection from Apple).
As I'll distribute my app using Enterprise distribution, I'm missing one of key features of AppStore - Auto/Manual updates. (I know, that I can show popup users to update application)
Also I know, that application can download dynamic framework with code, and also can download bundle with resources.
So my question: How can I download storyboard (compiled to nib) from remote host, and load it into project?
Or is there anyway to make something like Sparkle.framework on OSX, which will update all the bundle of my app?
You can't update it silently and automatically but you can ditribuite with TestFlight or similar services. Crashlytics present an alert to update if a new version is available (and then use itms-services) .
You can even use itms-services yourself and build your own distribution system if you like.
Take a look at Artisan. They allow you to build portions of your app on their web interface and dynamically swap out views and workflow. It is generally used for A/B testing but could be used for your purposes too. This way you could change significant elements of your app without needing people to update anything. You can even setup different views for different groups of people, and again, all after application launch.
It is also free for <10,000 users, which I am assuming would not be an issue for an enterprise application.
From the Dropbox API doc:
Use a single app key for each distinct app
If you build multiple apps, use one and exactly one key for each app
you make. This makes it much easier for us to debug issues when they
arise. That said, if you're just building the same app for different
platforms (for example, iOS and Android), you can use the same key.
It sounds like multiple-apps-single-key only makes it harder to debug. Does anyone successfully deploy multiple iOS apps with a single app key?
There are a few different scenarios mentioned in the Dropbox Platform developer guide you're quoting from, and it's a bit unclear which really applies to your question. To enumerate everything:
"multiple different apps (on the same platform)" e.g.:
MyCoolTaskApp for iOS
MyCoolTimerApp for iOS
In this case, you need to register different apps with the Dropbox API, which means using a different key in each (since they are different logical apps). Also, this way, users will see the different app names when they look at their linked apps list in their account.
"same app for different platforms" e.g.:
MyCoolTaskApp for iOS
MyCoolTaskApp for Android
In this case, you shouldn't register multiple apps with the Dropbox API, and you should use the same key in each (since it is the same logical app.)
"multiple versions of the same app (on the same platform)" e.g.:
MyCoolTaskApp for iOS Lite
MyCoolTaskApp for iOS Pro
In this case, you shouldn't register multiple apps with the Dropbox API, but due to a technical detail there would be a problem with trying to use a single app key in both, as noted under Can multiple versions of my app (e.g., free and paid) use the same app folder on iOS or Android? in the Dropbox Developer support FAQ. In this case, you should contact Dropbox Developer support for help with getting this set up correctly.
To answer your question overall though, each of these scenarios above have been successfully deployed by various developers, but you shouldn't deploy multiple different apps with the same key.
We currently have an English app on the AppStore and have decided to support another language. But I'm not sure where to start.
How should the app content be created to be able to support this? Should I just create two separate applications in their respective language and submit them both to the AppStore? Or do I have to create one app with some kind of mechanism that translates on the fly??
I somehow don't think that flooding the AppStore with multiple versions of my app would be the way to go (at least in the eyes of the Apple Review team).
Any ideas?
The usual way is to use the localization of iOS. You should not upload different apps!
See this link for a tutorial: How to localize an iPhone app