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.
Related
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.
Im developing an SDK and its deployment target is set to 9.0. Im using some API's that are deprecated in iOS 10 and above and others that are deprecated at iOS 13 and above.
My question is what will happen to an app that is consuming my SDK and its deployment target is set to iOS 14? will my SDK be affected? will my methods get properly invoked? will it crash the hosting app? is the behaviour under these circumstances is unclear? or maybe all will run perfectly?
Any light on this would be appreciated, thanks.
First things first, deprecation is the first step in the process of ending the life of an API and Apple is warning the developers that these APIs will be removed in one of the future iOS releases. Nobody knows when except Apple. There is certainly a wisdom in that (e.g security concerns, better API design, etc).
Developing an SDK which uses deprecated APIs is generally considered a dead end. I am sure you have your own reasons, however, anyone who uses your SDK will be asking themselves whether there will be any value or will there be a maintenance overhead.
There are certain issues during the development stage that you should be aware of. If the app developer of an app who uses your SDK sets the deployment target to iOS14, most probably Xcode will flag this up as a warning. It depends on other things such as the development language that you are using, whether it is already compiled etc.
Assuming there is a good reason for you to move forward, there are several scenarios on what could happen.
In Production, the very short answer to your question is, the application will crash if the API is removed in the next OS upgrade by Apple (if the app developer doesn't take any action before it is released). However, long answer is a little bit more complicated than this.
The best case scenario is Apple doesn't remove the API for a very long time e.g UIWebView. I think it has been at least 5 years now since Apple deprecated the framework, and technical you can still build an app with the UIWebView. That means you do not have to do anything (in theory).
However, if the API is removed by the new OS update, there are several scenarios:
The device is eligible for an OS upgrade, THEN the app will most likely keep crashing when the API is called by the app/sdk.
If the device is NOT eligible for an OS upgrade (e.g stuck on iOS 10), the app will still live for a while on these devices until the owner buys a new device (whether the app developers takes action or not). That particular app version should also be available through iCloud purchases/downloads. So customers can re-download that version even if they delete it etc.
For an active app developer, the first scenario shouldn't happen. I would expect them to test the app on the next beta of the OS version and take action if there is an issue e.g ask you to provide an update, or replace your SDK with another one.
The API removal process can be a little bit more informed and Apple might force your hand, but be still gentle. Apple may make it explicit and warn developers that any new apps, or app updates which contain the API will not be accepted to App Store. This ties the app developers hands. They need to make a choice. This warning would be months in advanced and you would put this work into your backlog and plan for it.
The scenario in bullet point 2, on the other hand, may not be obvious at first, and Apple is doing a pretty good job of convincing the customers to buy the latest devices. There is a relative 2 year cycle, so you may not find many customer using older phones which are stuck on older OSs. This may be ignored depending on your significance level.
The app developers may or may not be able to keep the min target of the app. If they are so adamant then most likely their app will not be compatible with the latest devices or Apple may refuse their updates (as above). Then that means it is pretty much the end of life of the app, only used by a handful of customers.
There is also scenario where Apple may also remove the applications from App Store and iCloud download which are not maintained for a certain period of time (this has happened).
We have a browser application and this application is using by different clients. Each client is using separate database and service. Regularly(quarterly) we are releasing the upgrade with enhanced features. But some of the clients may not upgrade to the latest. So different clients are using different versions of our product. There is no issue with this because each clients are using their own Database and service. Recently we build up a iOS app for the same application. In app store we can upload only the latest version of our app, how the clients in lower version can install respective version of their app? Latest version app may not work with lower version of service and Database
Different clients needs to install different versions of same app from app store.
In App Store Connect (where you manage your apps in the App Store), you can choose which versions you want to remain in the App Store after you release a new version. The purpose of this is to allow an older version to be downloaded in case the user have an older device or iOS version that don't support the new app version. - So I guess this feature is not really helping in your case.
I would suggest you make the same version for everyone, and then within the App (I assume your clients have a login) based on their user selects what you want to present them. - Connecting to their old database and deactivating the new features as an example. This will also give you the opportunity to showcase that there is new features which they may want to opt-in on.
You can release a completely new app for each version. Ex. YourApp 1.0, YourApp 2.0 (This is not uncommon, but it's usually more if the same app is radically changed/improved, and you want the old version to remain for some time until you retire it completely).
Hope this clarifies a bit :)
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.
I released an update for my App and it was approved. It was approve despite the fact that it included a serious localization bug where most users are getting the wrong language. Is there any way to quickly revert back to the previous version, suspend current downloads of the current version, or anything else that might help aid this issue?
I did read the following thread from a couple years ago:
Can I revert to my previous version app in iTunes Connect?
I was hoping maybe there is a more painless solution to this now.
Btw, I did thoroughly test the version before it was added as a new version. So, I'm still not entirely sure what's wrong or how to fix it.
It is not possible to revert the app version. You can upload the previous version as new version again to fix this.
One thing you can do is : "Expediting an App Review"
Please check the following link.
https://developer.apple.com/appstore/contact/?topic=expedite
Thanks
Here's a snippet from iTunes Connect Help page :
Question: The new version of my app on the App Store has a bug. Can I use a previous version to replace it?
No. You cannot revert to a previous version on the App Store. You must submit a new version.
Source : iTunes Connect FAQ
Obviously the alternative would be to submit a new build but ask for expedited app review.
But that means that either your app is event-related or you have a critical bug that you need fixed as soon as possible.
I believe that you can prepare for problems by creating a fallback version with a higher version number and submitting it for approval with manual publishing. That should cause it to be quiescent in your store until you choose to fall back, and you publish it.
I am not certain whether you can then submit improved versions with a lower version number than your fallback version.
I had to do this recently. I was able to adjust a previous version archive. I started by copying the archive and opening the copy, then editing the info.plist files, adjusting/incrementing both the version and build numbers at both the archive and app package levels. Then uploaded to iTunes, which recognized it as a new version.
Preface: I agree with the other posts here that you can't perform a rollback through the iTunes Connect itself. Even if you could, you'd suffer the lag time it takes for users to update to the rolled-back-version. But that doesn't mean we can't still rollback apps.
Retroactively, you cannot rollback an app. Proactively, however, you can instrument your app to enable future rollbacks after a build has been released and installed.
High-level steps:
Build each version of your application as a framework
For each release build, include both the current and old framework versions
On app boot, decided which framework to load and execute (include sane defaults)
When you want to rollback, update the cached values across all user devices and wait for the next app open.
This strategy uses similar mechanics to feature flags which are commonly used to enable/disable features without re-releasing. However, in this case, you're "feature-flagging" your entire app version.
Is feature flagging between embedded libraries against App Store Guidelines?
No. Embedding two versions of your app into one release is not against App Store review guidelines:
4.7 HTML5 Games, Bots, etc.
Apps may contain or run code that is not embedded in the binary (e.g.
HTML5-based games, bots, etc.), as long as code distribution isn’t the
main purpose of the app, the code is not offered in a store or
store-like interface, and provided that the software (1) is free or
purchased using in-app purchase; (2) only uses capabilities available
in a standard WebKit view (e.g. it must open and run natively in
Safari without modifications or additional software); your app must
use WebKit and JavaScript Core to run third-party software and should
not attempt to extend or expose native platform APIs to third-party
software;
Similar to feature flags, all code that you plan to run is included in the binary that you submit for review. What's more, as long as you are rolling back to releases that Apple already reviewed and approved, you're not breaking the spirit of the guidelines.
Does this hurt performance?
I've profiled this approach against many of the popular and heavy open-source iOS apps including Wikipedia, Signal, Firefox, etc. You can be smart about deduping assets and shared libraries, resulting in a sandwiched-app-bundle size of about 1.2x the original size (really just depending on how much code you changed). You also incur about a 50ms startup cost when choosing which version of the app to boot.
IMO, both time and size increases are worthwhile in return for the ability to selectively rollback users experiencing issues while you take time implementing a fix.
Do real apps do this?
Major apps feature-flag between dylibs all the time when launching new features and optimizing performance. I have also heard of major tech companies using this app-level pattern for their largest releases. I have a personal app in the App Store using this pattern, and I have helped other developers do the same.
How can someone do this for their app
If you are comfortable going deep on the Xcode build system, you can follow the steps outlined above and with some fiddling, start feature flagging your app version on boot. Note that you'll also need some form of caching and a server endpoint to update the on-device flag.
The implementation described above is also exactly how screenplay.dev implements iOS rollbacks. The tool:
Adds two build targets to your Xcode project, one for building the framework version, and one for bundling the final release build.
Serves as a repository for your old app build versions.
Provides a web UI for toggling live versions.