Xcode 8 / iOS 10 support coming in 8.1.1

[Fraser Gordon]

On 08/09/2016 17:37, Roger Eller wrote:
> What I meant to ask is, which specific NEW Android 7.0 features
> aresupported in LC? Where is the latest list of mobile features that
> wouldshow LiveCodes commitment for keeping parity between supported
> mobileplatforms?
> ~Roger
The reason more work seems to happen on iOS is because every time Apple
releases a new iOS update (e.g 9.0 to 9.1 or, in this case, the release
of iOS 10.0), we need to do a lot of work building new iOS engines and
adjusting to the (unannounced!) changes made in the new SDKs. Because
the versions of Xcode, macOS and iOS are tied together, this means that
we need to support a wide range of iOS SDKs simultaneously. (Currently,
the list is 8.2, 9.2 and 9.3 for device builds and 6.1, 7.1, 8.2, 9.2
and 9.3 for simulator builds). Of these, all but the 6.1 simulator build
are 32-bit/64-bit "fat binaries", meaning that the current release of
LiveCode ships 15 iOS engines (per edition, per release).

All this work is needed just to keep up with changes Apple have made -
it isn't about adding support for new features, it's just keeping things
working.

Android, on the other hand, is very good about maintaining
compatibility. We currently build one engine that works with a wide
range of NDKs and SDKs. Currently, we're at API level 17 needed to build
the engine (Android 4.2.2) but it'll run on Android releases from 2.3.3
onwards (though with a reduced feature set).

Adding new platform-specific features to the core engine is surprisingly
difficult and writing externals using Android APIs can be tricky (due to
needing to use both C++ and Java) so not many third-parties do it, which
is why we're busy working on the 'Infinite LiveCode' project
(https://livecode.com/project/infinite-livecode/). Currently, we're
improving LiveCode Builder to get FFI bindings for Java working (see
https://github.com/livecode/livecode/pull/4438 for progress) so that
widgets and libraries can be written to access Java APIs, the main
use-case of which is to make wrapping Android features much easier.

Fraser