Unfortunately, JIT will never be allowed on iOS because it invalidates the security model of the iOS App Store.
The current security model requires that all iOS App Store executables are monolithic - with the only exception being Apple-provided Apple-allowed dynamic libraries. You cannot publish an iOS App Store app that includes separate third-party dynamic libraries - they have to be statically linked into the final executable, which Apple then encrypts during the signature process.
This allows Apple to have 100% vetting control over the native code published in their iOS App Store. You can't side load unsigned code / code they haven't seen. There was actually an exploit / proof of concept where someone published a financial app in the App Store that called home and loaded arbitrary bytes into executable memory. The bug was patched and the developer was banned from the App Store.
A JIT would effectively allow the same thing: arbitrary native code execution on an iOS device that isn't part of an executable Apple has seen / signed.
However! This does not mean python is unavailable in the App Store. Python for iOS, Pythonista (my favorite), and several other flavors of interpreter already exist. It's just that they're bytecode interpreters only - no JIT allowed. And any attempts to use ctypes to dynamically load a module actually triggers a segfault (it's an intentional part of the iOS dynamic linker that does this - segfaults loading anything non-standard).
So go ahead and enjoy python on iOS - just don't hold your breath waiting for JIT.
It actually makes a lot of sense. Preventing pages from being executable makes exploitation so so so much harder... Because you will need to do ROP (Return oriented programming) and Apple is quite good at ASLR (Address space layour randomization).. It also means that malware can't just load external code from a C&C server etc.. And yes, it sucks that all this means that one can't JIT.
Edit: Allowing executable pages would also break mandatory code signing.
Changelogs like "Bugfixes to cffi and ctypes" are pretty useless. Do these bugs affect my code? Is my code going to explode horribly if I don't upgrade? Is my code going to explode horribly if I do upgrade? etc.
They're useless for you. It typically means someone posted a bug on the issue tracker and it got fixed. If you did not try PyPy before, you can't know if it affects you. If you did and there were bugs in cffi/ctypes, this is a time to try, if you did and it worked it should continue working.
I know this is useless for you, but be a little understanding, most releases that are genuinely useful contain tons of stuff like "we fixed performance of this corner case" or "we fixed this obscure crash" etc. What else would you suggest to put there?
Also, how on earth is what you wrote related to ARM JIT support in the title?
Good point. Most projects do it this way, and I think it's kind of good to have a high level summary like this. However, I've also seen projects that also link to specific related issues -- or even better blog pages, or documentation related to it. Mozilla with firefox does it this way for example.
Your concern whether this release may break your code is only a test run away ;) But seriously... this is a valid, and common concern. I'd assume they are not intentionally introducing breaking changes, considering it's still targeting CPython compatibility. Also, there are no explicit breaks mentioned -- but I guess it might be good to communicate this explicitly.
As we say so often in the Python commmunity, "Try It And See." Do you use cffi and/or ctypes in your code? Have you run your tests against this newer PyPy?
This could be the missing ingredient in the new entrant mobile OSs: A managed language runtime. This + Qt bindings could make a nice app runtime for an OS like Jolla. Otherwise, in most cases, your choices are Web apps or Qt apps in C++.
