[izacus]

> The second thing is recent requirement to provide 64-bit version of each app. My app depends on framework written in C++ with additional libraries in C. I can't and won't spend time to get the build for 64-bit version working. Google sent me a mail that "All new apps and app updates are required to provide 64-bit versions of any 32-bit native code they provide". So I won't be able to update existing app to existing users ever again, for non-technical reasons.

So the "non-technical" reason here is that you don't want to provide a build for users with 64-bit devices?

[jmiskovic]

I'm not against 64-bit build, but it's too big effort. This feels like blackmail: "Either invest 40ish hours of your time to compile the framework and all dependencies to 64-bit, or you won't be able to update the app for existing users anymore"

I don't care about 64-bit devices. I'm fine with them not being able to install or run the app, if that's how it is. People with 64-bit devices can easily afford better products that my app tries to replace. I don't own device to test the 64-bit version, and I don't know anyone who does.

I care about existing users. I kept minimum SDK version as low as possible so that my app might reach all the cheap phones in poorer parts of world. It actually works today across many different devices, so what has changed?

[ryandrake]

For all but the most complex, or assembly-optimized, or just poorly written software, supporting 64-bit should be no more than a recompile. When I started producing 64-bit versions of my iOS apps, at first I didn’t even know it happened because Xcode just did it for me. Any yes, they included C and C++, and 3rd party code. It took zero hours to support. It was almost too automatic for comfort.

[saagarjha]

You might not always have access to the source of something you ship with your app.