Clarification wanted about 32bit apps and iOS 11 (maybe from a develloper?)

richardyot

I contacted the Flying Haggis developer about iOS11 comparability, and he sent me this reply, which is too technical for me to really understand - does anyone know if this means the app will ber OK with iOS 11:

Yes, we're aware of the recent press on this point. It shouldn't be an issue, since Flying Haggis 1.2 is a universal binary containing both 32-bit and 64-bit compiled slices. Specifically, it contains 3 slices to support armv7, armv7s and arm64 architectures. Therefore it already complies with Apple's suspected requirements for iOS 11.

It sounds like the app should be OK, but my concern is that the 32bit libraries are included in the package.

Looping_Loddar

I would say the developer knows that there could be an issue with 64bit compatibility, but he does not assume that this is the case because the developer thinks: "Therefore it already complies with Apple's suspected requirements for iOS 11".

I am bit unsure what the developer is talking about when he wrote "suspected requirements".

"suspected"?? I thought it is quite simple:

https://developer.apple.com/news/?id=09072016a

That means: The developer has to use > Xcode 8.
(->64 bit)
This is all. The developer maybe has to recompile his project(s) and test it/them again.

(i am not a developer - i am just guessing)

[Deleted User]

@richardyot said:
I contacted the Flying Haggis developer about iOS11 comparability, and he sent me this reply, which is too technical for me to really understand - does anyone know if this means the app will ber OK with iOS 11:

Yes, we're aware of the recent press on this point. It shouldn't be an issue, since Flying Haggis 1.2 is a universal binary containing both 32-bit and 64-bit compiled slices. Specifically, it contains 3 slices to support armv7, armv7s and arm64 architectures. Therefore it already complies with Apple's suspected requirements for iOS 11.

It sounds like the app should be OK, but my concern is that the 32bit libraries are included in the package.

The developer is saying it shouldn't be an issue. It currently has code so that it works on 32 bit devices and 64 bit devices. By suspected requirements, the developer is saying that iOS 11 hasn't been released yet by Apple so they're going by the best current knowledge available to the developer. At this point I don't think any developer can do more than this.

The armv7, armv7s, and arm64 refers to the brains in the iOS devices and covers everything from 2009 onward.

DaveB

In my reply to Richard I used the phrase "Apple's suspected requirements for iOS 11" because at this point no-one knows the facts. An iOS 11 beta is not yet available, and Apple are well known for changing requirements on a daily basis.

However, this lack of concrete information hasn't stopped the press from foaming at the mouth about a coming iOS 11 app-pocalypse, bless 'em.

The sum of my knowledge is this - as long as an app supports the arm64 architecture, it will continue to work in future iOS releases. That is all I (or any other developer) can say for sure at this point.

brambos

@DaveB said:
In my reply to Richard I used the phrase "Apple's suspected requirements for iOS 11" because at this point no-one knows the facts. An iOS 11 beta is not yet available, and Apple are well known for changing requirements on a daily basis.

However, this lack of concrete information hasn't stopped the press from foaming at the mouth about a coming iOS 11 app-pocalypse, bless 'em.

The sum of my knowledge is this - as long as an app supports the arm64 architecture, it will continue to work in future iOS releases. That is all I (or any other developer) can say for sure at this point.

^ What he said.

BiancaNeve

I'm curious as to what needs to be done to a 32 bit app to make it 64 bit. Is it easy or a lot of work.

brambos

@BiancaNeve said:
I'm curious as to what needs to be done to a 32 bit app to make it 64 bit. Is it easy or a lot of work.

If it doesn't use deprecated libraries, 3rd party 32 bit frameworks or XCode features that aren't available in the current version of XCode it could be as easy as opening, recompiling and resubmitting to the Appstore.

However, Apple are known to change lots of things in terms of XCode project settings, language features, library calls, etc. so opening an old project could easily lead to days and days of hairpulling frustration trying to figure out the meaning of weird error messages and build-failures, trawling dozens of Stackexchange questions of miserable developers running into the same brick walls.

TheVimFuego

@brambos said:

@BiancaNeve said:
I'm curious as to what needs to be done to a 32 bit app to make it 64 bit. Is it easy or a lot of work.

If it doesn't use deprecated libraries, 3rd party 32 bit frameworks or XCode features that aren't available in the current version of XCode it could be as easy as opening, recompiling and resubmitting to the Appstore.

However, Apple are known to change lots of things in terms of XCode project settings, language features, library calls, etc. so opening an old project could easily lead to days and days of hairpulling frustration trying to figure out the meaning of weird error messages and build-failures, trawling dozens of Stackexchange questions of miserable developers running into the same brick walls.

Sounds much like my average 9(ish) to 5(ish).

richardyot

@DaveB (and @brambos) thanks so much for chiming in with that clarification. There is a lot of confusion about this issue, partly because of Apple of course. My fear was that there was a risk of losing one of my favourite apps (Flying Haggis), so I'm delighted to hear that it should be OK.

@DaveB do you have any plans for an update? I would gladly pay for new updated app with new features. Or IAPs in the existing one. I realise that App Store economics don't always work out for developers.

Will

@brambos said:

@BiancaNeve said:
I'm curious as to what needs to be done to a 32 bit app to make it 64 bit. Is it easy or a lot of work.

If it doesn't use deprecated libraries, 3rd party 32 bit frameworks or XCode features that aren't available in the current version of XCode it could be as easy as opening, recompiling and resubmitting to the Appstore.

However, Apple are known to change lots of things in terms of XCode project settings, language features, library calls, etc. so opening an old project could easily lead to days and days of hairpulling frustration trying to figure out the meaning of weird error messages and build-failures, trawling dozens of Stackexchange questions of miserable developers running into the same brick walls.

If you've written a bunch of assembler code by hand that is specific to older (32bit) ARM architectures, that could also be a reason. I'm fairly certain this is the problem with Nanostudio 1. Would require a whole lot of low low level code updates for zero feature/performance return.

Will

@TheVimFuego said:

@brambos said:
could easily lead to days and days of hairpulling frustration trying to figure out the meaning of weird error messages and build-failures, trawling dozens of Stackexchange questions of miserable developers running into the same brick walls.

Sounds much like my average 9(ish) to 5(ish).

Ha! Mine too. Particularly the SO part.

moodscaper

@brambos said:
However, Apple are known to change lots of things in terms of XCode project settings, language features, library calls, etc. so opening an old project could easily lead to days and days of hairpulling frustration trying to figure out the meaning of weird error messages and build-failures, trawling dozens of Stackexchange questions of miserable developers running into the same brick walls.

Haha! That sounds like my average 9(ish) to 9(ish) ! I don't get much time to work on my own app(s) these days.