XCode 9.3 32-bit warning

32-bit architectures are disappearing. Future versions of macOS won't support them at all (e.g. see appleinsider.com/articles/18/04/11/new-macos-alert-notifies-users-apple-will-soon-end-32-bit-app-support) so you can't really ignore the need to update your app.

If you have a user base that will be using older 32-bit-capable versions of macOS, then you will have to build a 32-bit version of your app using one of the older versions of Xcode (and that Xcode will likely have to run on a development system with an earlier version of macOS). This app version won't run on newer versions of macOS, so you're likely going to need two versions of your app.

Thanks, I am fully aware of Apple's 32bit deprecation's process.

As the majority of audio plug-in developpers, we've been shipping both 32 and 64bit versions for years.

Some people need to use 32bit versions because they have legacy requirements, don't want to take breaking a perfectly working setup, etc.

On the other hand of course we need to stay up-to-date and compatible with the latest macOS versions, so using the latest stable XCode makes sense.

I don't think it's too much to ask for a setting to hide the warning once we've seen and ackowledged it,

the same way that we can disable the 'Enable recommended settings' message when updating XCode.

Different devs have different requirements / constraints. An IDE shouldn't force specific recommandations on us !

Best,

Lorcan

> ask for a setting

As always, feel free to file an ask via the bug reporter link below, being sure to add your report # to your thread for reference, thanks and good luck.

>> An IDE shouldn't force specific recommandations on us !

It's not forcing a recommendation on you, it's warning that your project configuration won't be supported at all, at some point in the not-too-distant future. That means, not supported by macOS, not just Xcode.

It should not be infeasible for you to produce 32-bit audio units separately, using (say) Xcode 8.3.3 running on (say) macOS 10.12, on a separate development Mac or via a VM on your regular development Mac. It does require a one-time reorganization of how you build and distribute your products, but it's better to make that effort now, rather than waiting until the development ecosystem has completely changed.

(I've been through this before, with a PPC product that depended on CodeWarrior and its class libraries. It would have been feasible to make some kind of Intel transition while both architectures were still supported, but that wasn't done then, and it became impossible to fix that retroactively.)

Quincey,

thanks for your input.

VM / separate build is not feasible for us.

That would mean abandoning the convenience of universal binaries (required by some plug-in formats),

plus we're a small shop and don't have enough resources to support the overhead.

Also you have to take into account that we're building plug-ins, not standalone apps,

so the impact of abandoning 32bit is not just a matter of asking the user to install the 64bit version instead.

One could argue that PPC is a different ***** entirely. To my knowledge no hardware ever supported both PPC and Intel ISA.

XCode is basically a front-end to LLVM which hopefully will allow us to compile 32bit for the foreseeable future !

Anyway, I'll stick to 8.x if necessary until 32bit is dead and buried (and hopefully sooner than later, when all major audio DAW's current versions are 64bit).

>> no hardware ever supported both PPC and Intel ISA

It did. Intel-based Macs (starting around 10.5, whenever the hardware was introduced) ran PPC software via Rosetta, which made it easy to ignore the conversion problem, since existing binaries ran just fine. Rosetta was discontinued in 10.7, which was where the trouble started.

>> XCode is basically a front-end to LLVM which hopefully will allow us to compile 32bit for the foreseeable future

That's basically what I'm alerting you to. The clang compiler will presumably compile 32-bit object code for pretty much forever, but Xcode may lose the ability to package such code. Further, after a certain point there may be no universal binaries in their current form, so you might not have that option for the foreseeable future.

The take-away (as I see it) is that if you want to preserve your current business model, then you are forced to preserve your development environment as well. That means preserving both a suitable Xcode version and a suitable macOS version, because you can't even assume Xcode 8 will run on future macOS versions.

Rosetta was a software emulator, so no recompiling needed, not what we're talking about here !

There actually are some (paying) products available that make it possible to run 32bit plug-ins under a 64bit host and vice-versa.

Anyway, I'll leave it there, thanks.

I'm in the same boat. There should be a way to suppress this warning.

>>>It's not forcing a recommendation on you, it's warning that your project configuration won't be supported at all, at some point in the not-too-distant future.

But the not too distant future isn't here yet, and plenty of people will still run 32-bit apps either by not upgrading or using virtuals. My personal plans are to drop 32-bit support when the future actually arrives, but I'd like to be able to produce one more 32-bit release before then. It looks like I'll have to downgrade to the previous version of XCode for the forseeable, because the warning is not only an irritant but it appears XCode no longer recognizes 32-bit APIs even in older SDKs.

This new release is capricious, high-handed, and pointless. The transition could have been kind and achieved the same results, but instead Apple chose to be cruel.

Not sure capricious means what you think it means...

The notice went out June last year and the next macOS is due inside 6 months, I assume. Seems more than kind, given near 18 months to adopt.

>> plenty of people will still run 32-bit apps either by not upgrading or using virtuals

This is not a very accurate representation of the situation. Everyone using a Mac running macOS 10.6.8 or above can run 64-bit apps, including a 64-bit version of your app. Every Mac released in the last 10 years runs 10.6.8 or above.

The only people who would be left out are those who have Mac hardware that is well over 10 years old, and those who are forced to run your app in 32-bit mode for some other reason.

These might be people you want to continue to support, but it's not "plenty of people".

>> I'd like to be able to produce one more 32-bit release before then. It looks like I'll have to downgrade to the previous version of XCode

You don't necessarily have to "downgrade" for this. You can install Xcode 8.3.3 alongside the current version, and I'd expect it to work in 10.13 (but with the 10.12 SDK).

I sincerely don't understand what the fuss is all about.

As explained previously, some users still ask for legacy 32-bit compatibility, for various good reasons.

We're all responsible adults here, if one chooses to deliberately ignore/silence a warning, that should be his/her responsibility alone.

I'm only asking for an option to silence that warning - regular devs can just leave it to default (enabled),

basically making everyone happy.