How to migrate users from old 32-bit app to the new 64-bit app?

Hello,


I have an old iOS app designed in 32-bit world back in 2011 (almost 6 years on the App Store!).

The old app (version 1) was impossible to re-compile for 64-bit architecture due to key 32-bit library dependencies, so it just stopped working under iOS 11.


The old app still (in 2017) has several thousands app users, and I did not want to abandon the entire project and leave them without any way to continue using the app under iOS 11, so I was re-writing the project from scratch for more than a year, and just released the the new version (fully 64-bit compatible) on the App Store in time for iOS 11 release.


Unfortunately, there was no "cloud-way" to transfer user data from the old app to the new one, so in order to help users migrate to the new version, I submitted a minor migration update for the old app that would "lock" the old app into the same App Group as the new version, so the new app can automatically read and import all user data from the old app to the new one. The old app would stop working under iOS 11 so this update would be totally safe for our users.


So simply this update would turn the old app into a "bridge" app just to help users migrate. After the majority of users migrate (in a couple of weeks), I would simply remove the old app from the App Store.


However, the update was rejected because of "4.2. Minimal Design".

Surely, it's has minimal design, and this would be a strong and objective reason to reject some _new_ app, but for my case (32-bit obsolete app) I found this way to be the easiest for app users.


What other methods of migrating users from an old app (that can not be updated due to old 32-but design) to a new one would you suggest?


With the release of iOS 11, I'm receiving lots of questions from the users of the old app about the migration, but Apple's rejection put me into a corner... I have no bright ideas on how to help users migrate.


Any ideas would be appreciated! Thank you!


(Releasing the new app as an update to the old one was not the case because feature set changed significantly. And technically the new project is a complete new story.)

Replies

So you felt compelled to render the old app useless, instead of simply replacing it entirely with the new app?


You (and your users) would have been better off if you had just released the 64-bit version as the update to the 32-bit version, even if the feature set was different due to loss of the supporting libraries.

Thanks for sharing your idea! I agree that a common update would be the easiest solution for most apps in similar case.


In my particular case, I was in a hurry to release new 64-bit app in time for the release of iOS 11, and did not have chance to integrate certain app features that were supported by the old version, e.g. cloud sync, data sharing, etc. Those features were significant and crucial to some users (who are still on iOS 10 and are capable to use the old version), and it would be wrong to take away these features with the update at once.

All these missing features are to be added to the new version, and it will just time a bit more time, i.e. few weeks.


Releasing as a separate app would allow each user to pick the right moment for migration, so this scenario seemed like the best (and soft) one.


To my opinion, rolling out new major version as a separate app sounds like an absolutely legal thing, so I'm curious about other fellow developer ideas on how to approach this properly. I believe some other app developers might had been in the same position.

Sounds like a fair approach. What does the app do? Can you provide some screenshots?

It's a to-do list app named Pocket Lists.

It was initially build in 2011 in Lua with an intention to make the app cross-platform. It was a mistake that lead to a 32-bit lock-in.


Unforunately, Apple rejected our approach to make the migration the described way. Looking for other options now...