Does Version 7.0.4 work with Xcode 6.3.1?
ambassador at fourthworld.com
Sat Apr 25 21:18:49 CEST 2015
Excellent info, Mark - thanks!
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
Ambassador at FourthWorld.com http://www.FourthWorld.com
Mark Waddingham wrote:
> 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
> 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
> 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
> Anyway, I hope this helps to explain the current situation, and also
> what we are doing to improve it moving forward.
> Warmest Regards,
> 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