Hacker News Reader

Comment by nevster | Hacker News Reader

I recently had a similar experience updating an old iphone app that was written in Swift 2.

I had to use an old 2009 iMac with a copy of Xcode 8 to migrate to Swift 3, then a 2016 MacBook Pro with Xcode 10 to migrate to Swift 4. Then I could finally perform the final migration and compile/deploy on my M1 Macbook Pro. It was ridiculous!

View on HN

You kinda did this to yourself by using Swift when it was not stable yet. Meanwhile old Objective-C code continues to work just fine on iOS 15.

I agree wrt Obj-C but as a non-Mac developer it would not have been obvious to me a priori that something that was declared version 2 already wasn't stable.

(I would absolutely assume that if it was officially still unstable that would have been documented somewhere ... I would absolutely not assume that I would have noticed)

Agree - 99.9% of Java 1 apps will still compile and run just fine on Java 17

Unless you used XML.

Are you talking about jaxp? Don't old jaxp jars still work?

The parent comment is probably talking about the J2EE packages which used to come with the JRE before Java 11; a lot of code which used to run on Java 8 and earlier no longer runs on Java 11 and later unless you manually add a couple of extra JARs to the classpath (and good luck knowing which ones are needed when reflection is involved).

However, the grandparent comment is talking about Java 1, which is before J2EE; the thing which would break code from that time is probably not going to be XML, but instead things like Applet support. There's a good chance that a Java 1 app is in fact an applet designed to run within a browser, and no longer runs fine on Java 17 since the Java plugin is no longer supported.

I know very little about Mac/iOS application development, but my impression from developer friends and acquaintances is that Swift uses an unusual variant of semantic versioning, in which all real numbers are assumed to be unstable releases.

(it's a joke, I love you, Swift developers)

I’m sure I’m going to be running the HN gauntlet here, but AS3+Flex was a beautiful time to be coding for me. I was paid to basically knock corporate front-end software out (what would now be certainly termed SPAs, oh, how we reinvented the wheel…) day in and day out when Flash wasn’t a very naughty, bad swear word. We knew how it would run in every browser, it was responsive and it seamlessly integrated with all our backend web services. Easily. I honestly feel that it’s only in the last year or two HTML/JS is now at parity with where we were with this stuff nearly 10 years ago. Yes, it is clearly much better now for all sorts of reasons, I won’t sugar coat it… Flash also sucked badly. Very badly. but… AS3 with Flex “bindings/proper ties” was a beautiful set up. It just worked. Always. Everywhere.

The only other language I’ve felt a serious affinity with was Objective-C. It’s the only language where I knew when I hit compile/run any errors were on me. Maybe it’s just having spent years in those ecosystems/languages and developing what some might call “mastery”, I never got surprised. I never felt like a master. People above me always knew so much more. I do remember writing a couple of thousand lines of Obj-c over two heavily caffeine fuelled days, hitting run for the first time and it just worked. Years on I still find “gotchas” in JS and CSS that I just never found in those languages. Maybe I thought about code more back then? Constant integration and hot reloads all the time, just make it all feel a bit different. Maybe I’m just set in my ways from spending a day typing out Spectrum machine code from the back of a magazine? Anyway… my favourite language of all time is Objective-c, that’s all I actually wanted to say. Rant over.

I done AS3 and Flex4 Adobe AIR apps, AS3 was similar to TypeScript . And Flex4 had very good layout components and widgets , IMO web is still behind Flex4 for SPAs advanced applications.

> it would not have been obvious to me a priori that something that was declared version 2 already wasn't stable

Swift came out in Sept. 2014 and v2 in 2015. Just knowing that the language was 1.5 years old would bring long-term compatibility doubts to mind.

That’s not really fair. For example Go programs written in v1.0 are still mostly compilable (the few tweaks you do need to make aren’t substantial).

Rightly or wrongly Apple very much decided Swift should take a different approach to backward compatibility.

You're always rolling the dice with new languages; Go just happened to be mostly compatible. If you want something that will compile in 20 years, pick something with a track record.

My perl5 version 8 code still runs perfectly on version 34, and for all people's (often valid) dislike of perl still helps a lot of companies make a lot of money.

That wasn't the point I was trying to make in that particular comment though.

Most languages offer some guarantee by the time they hit version 1, let alone 2. Take Python for example, v2 took a decade to deprecate.

Swift is the edge case on this one. Not the norm.

Is Swift 4 not yet stable? The point is, I couldn't even migrate from Swift 4 to the latest with my current M1 MacBook. (You need old XCode to migrate from 4.0 to 4.2) What's surprising is the very quick dropping of the migration tools from Xcode.

Out of curiosity (I mostly use old languages so I'm definitely missing something), why does migrating require support from Xcode? It's just text, right? I mean fundamentally you could just copy the files over and then fix them to be compatible with the changes in the language, right? (Does Xcode have some automagic tool to convert between different version of the language?)

Technically, yes. In the easiest cases it's just changes in library function names so effectively the migration tool is just handling all that search and replace for you. Of course there's more complex stuff than that. There's also all the ancillary build files and project setting files that get updated. All pretty tedious to investigate and do by hand, especially for someone like me who just wants to get their old app running again on the latest iOS.

Pretty annoying that they'd pull the rug like that. Actually, kinda worse than the bad-old way of doing things. I'm sure if they hadn't set the expectation that such a tool would exist, you'd have set your code up to be more easily search/replaced (or sprinkle macros around, etc).

> Out of curiosity (I mostly use old languages so I'm definitely missing something), why does migrating require support from Xcode?

That's just Apple being Apple unfortunately.

Wait, did people know at the time that Swift 2 was "not stable"? What version of Swift became "stable"?

I guess for some definition of stable[1] you could say that we knew Swift 2 was not that, and by the time Swift 5 was released we knew it'd reached that milestone.

[1] https://www.swift.org/blog/abi-stability-and-more/

>You kinda did this to yourself by using Swift when it was not stable yet. Meanwhile old Objective-C code continues to work just fine on iOS 15.

In pretty much any other programming language, upgrading to a new build enviroment / ide / compiler does not require a staged upgrade. I can take my android studio project from version 2.x and open them in the latest ide without having to step through intermediate versions. Of course I expect a sea of red, but the ability to migrate directly is present, and it's not in xcode.

edit: And to make things worse, you cannot just download an older version of xcode because it might not run on our newest os/mac. SMH. Planned obsolescence FTW!

Reply on news.ycombinator.com