Any timetable you can comment on for an arm64 slice to the framework? I’m working to add speech recognition to my app(s) and this is one of the few frameworks left I need to support arm64 and the iPhone 5s (And presumably the new iPad here next week).
Thanks for the response!
Wes
Good question. I only just received my long-ago-ordered 5S yesterday (OpenEars has to be tested for 64-bit compatibility on a real device since a fair amount of its important code isn’t used on the Simulator), so this is the next issue up after the upcoming 1.6 release that is currently in testing. Exact timeframes aren’t possible but I know it’s important to get out ASAP.
]]>http://stackoverflow.com/questions/18983975/run-32-bit-library-on-iphone-5s-64-bit
But as I said, I appreciate that everyone wants to support arm64 soon and I do as well.
]]>Thanks for the response and congrats on your new iPhone 5S!
Yes, agreed on all points. I could remove arm64 from the valid architectures list and release, however, here’s my reasons for supporting the arm64 slice:
– All current and future high-end iPhones and iPads (maybe even the mini at some point) will be using the new 64-bit chip.
– 64-bit uses the the new, redesigned 64-bit iOS frameworks. Object creation is about half the time and there are many fixes (read fixed memory leaks) here still affecting the 32-bit frameworks.
– If your app supports 64-bit, iOS doesn’t have to load in the 32-bit framework. This give more memory availability to your app.
– My app deals with heavy real-time video processing from multiple sources. The performance boost I’m seeing with arm64 is very significant.
– My user base is already at > 75% iOS7. iOS 5 is less than 2%. My next app update will only support iOS 7. Older users can always download the latest available for their device. But any new features (like voice) will be an iOS 7 only feature for my app.
I do use a host of other libraries where most have converted to offering an arm64 slice (however, I am still waiting on one other library to make the conversion). I’ve seen these other libraries do it a multitude of ways. Some have found a way to support back to 4.3 in one library.a file. Other’s have opted to release 2 frameworks, one that targets iOS 5 and below and another that targets iOS 6 and up (including arm64).
With arm64, there are some great reasons to support it, but I do sympathize and agree that supporting a new slice with the backwards compatibility restrictions can be difficult.
Thanks for all that you do. I’ve been playing with the demos (including Rejecto) and I’ve VERY impressed with what this on-device speech recognizer can do and I’m really looking forward to offering this as an upsell feature to my apps.
Thanks!
Wes
We’re in complete agreement; your points are 100% on the money and I’m actually looking forward to seeing if there are new features that can be supported that will take advantage of the strengths of the new architecture as it becomes more mainstream. I wanted to clarify just so that someone else reading this discussion doesn’t think they can’t make an app for the 5S at all yet, and to head off potentially having to answer that misconception in other channels. Thank you for your kind words!
]]>Agreed. arm7/7s/32-bit still works on the iPhone 5S. However, taking the time to convert to arm64 really impressed me with how easy it was to do (maybe 2 days tops) and the performance gains I got from running native 64-bit code on the new iPhone.
Hopefully the OpenEars code base won’t give you too much trouble to compile as arm64.
Wes
]]>Main app source:
400+ source files
~170k LOC
COTS library to support real-time video streaming decoding (I have to compile this on my own):
Thousands of source files
??? LOC. Easily 400k+ LOC
I didn’t find any issues with the wider bit definitions for integers, etc. In fact I could have just done a recompile and left the hundreds of warnings in place and the app worked perfectly. The majority of the time spent was cleaning up the warnings (mostly NSInteger casting).
Now, if you are doing some intense bit shifting work where you need to detect the end of the 32-bit register, then I could see where moving to 64 might cause you some headaches.
Hopefully it won’t be too bad for you; I’m sure every project will have a different experience.
Good luck! (and I’m eagerly anticipating arm64 support :)
Wes