Does Version 7.0.4 work with Xcode 6.3.1?

Mark Waddingham mark at livecode.com
Sat Apr 25 15:02:37 EDT 2015


On 2015-04-25 18:20, Richard Gaskin wrote:
> It seems that every time Apple updates Xcode it breaks LC, requiring
> the team to set aside other work and rush another build out for that
> one OS.  Many of the 7.0.x/6.7.x builds seem to fall into that
> category, and those of us waiting for resolution on issues for other
> platforms find this as frustrating as I'm sure the team does.

It is somewhat frustrating at times - yes (particularly as Apple have 
upped the pace of Xcode and iOS updates recently).

> Working with Android is smooth as silk by comparison, rarely requiring
> any updates at all.

Android is a slightly different beast than iOS - partly because Google 
has done very well to make every Android release a superset of the 
previous one and thus older APIs and methods continue to work fine as 
the platform evolves; and partly because there isn't an issue with 
dynamic linking.

> What is it that makes the relationship between LC and Xcode so brittle
> that it requires revision with every Xcode update?

There are three factors here - technical, legal and resource.

The technical issue is that iOS apps must present themselves as a single 
statically compiled executable - you are not allowed to load non-system 
dynamic libraries at runtime. As LiveCode supports native code 
externals, these cannot be done as dynamic libraries as they can be on 
all the other platforms.

Instead, we have to 'mostly-link' the engine, and 'mostly-link' each 
external. The Standalone Builder performs the final link step - and this 
step requires the full iOS SDK to be installed (hence the dependence on 
Xcode). Moreover, because all the mostly-linked pieces have been 
'mostly-linked' against a specific iOS SDK, the Standalone Builder needs 
access to the iOS SDK with which they were 'mostly-linked' in order to 
be able to build the final fully-linked executable.

So, if you have 6.7.4 which contains products built using the iOS 8.2 
SDK, you cannot use Xcode 6.3 to build a standalone because Xcode 6.3 
does not contain the iOS 8.2 SDK which LiveCode needs to perform the 
build.

The legal issue is that (as far as I'm aware) you are not allowed to 
distribute 'publicly' any derived works of a beta SDK - the terms of the 
iOS SDK Agreement for Beta releases is more restrictive than that of the 
non-Beta releases (basically, only paid-up members of the Apple 
Development Programme for iOS are allowed to access and use it). This 
causes a timing issue for us, as it is dubious as to whether we are 
allowed to distribute builds of LiveCode which contain components which 
are linked against a Beta iOS SDK (there may be a more optimistic 
interpretation, but I always tend towards the severely conservative when 
it comes to long, complex, software licensing agreements!).

The upshot of this is that it results in a bit of a race for us as soon 
as Apple 'decide' to make their latest and greatest work public.

The third issue is that of resources. Right now doing a build for a 
release of LiveCode takes a considerable amount of man power - this 
means we can't be quite as agile with releases as we would like and have 
to roll iOS SDK updates into the current maintenance cycle.

> Is there anything that can be done to anticipate and work around what
> appears to be a disregard for backward compatibility in Xcode?

In terms of improving the current state of affairs then...

On the technical side of things there are options open to us in terms of 
avoiding a direct dependence on the iOS SDK at the Standalone Builder 
step (if we had enough engineering resources to pour into such a 
project, that is). However, any technical solution along these lines 
opens us up to legal issues (particularly with the Google vs Oracle 
debacle still apparently 'not quite resolved', and restrictions imposed 
with regard 'reverse engineering', 'fair-use' and the DMCA).

On the legal side of things, perhaps a more 'optimistic' reading of the 
various SDK license agreements might help. However, as Ralph points out 
- if you are worth multi-billions of dollars, you get to set the rules - 
and I think it is wise for us to be conservative in this regard.

On the resource side of things then this is where we can and are doing 
something :)

The biggest bottleneck we have right now to getting releases (whether 
they be dp's, rc's or gm's) is the final build of the LiveCode 
distribution. This is something we currently have (and have had for a 
couple of months) people working on. We are currently in the process of 
fully automating builds of LiveCode, with the ultimate aim of achieving 
all-platform continuous integration.

When we have fully automated builds, it will free time from actually 
preparing the final builds and will hopefully mean we can revise our 
current process on iOS SDK updates and which releases to expect them in 
(for example, it should mean that is possible for us to add a new iOS 
SDK to the most recent stable versions of each branch we have as a gm-2, 
rather than having to roll them into the next maintenance release).

Anyway, I hope this helps to explain the current situation, and also 
what we are doing to improve it moving forward.

Warmest Regards,

Mark.

P.S. IANAL applies to any mention of 'interpretation' of the legal 
documents mentioned above.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps




More information about the use-livecode mailing list