Does Version 7.0.4 work with Xcode 6.3.1?

[Richard Gaskin]

Excellent info, Mark - thanks!

-- 
  Richard Gaskin
  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
 > 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