4 ms·

hm, so they rewrote the whole platform from scratch in <totally hip language of the month> and it didn't all crash and burn? That's kind of surprising - this is

hm, so they rewrote the whole platform from scratch in <totally hip language of the month> and it didn't all crash and burn? That's kind of surprising - this is usually a really stupid idea because you often end up mostly solving the problems of the v1 architecture but introducing a whole bunch of different, equally painful problems - but with the added headache of the whole codebase being newish.

melling 10y ago
Problems aside, Swift is the future of the Apple platform. It's a much less verbose language than Objective C. (no headers, type inference, no @, no ;) https://h4labs.wordpress.com/2016/02/09/should-i-use-objective-c-or-swift-for-writing-ios-apps/ https://h4labs.wordpress.com/2016/02/09/should-i-use-objecti...
- beaconstudios 10y ago
  my point is that a full switch-over is usually a terrible idea. I don't know if an incremental change-over from ObjC to Swift is possible in the Apple ecosystem, but if it is that's almost always the better option in my experience.
  - valuearb 10y ago
    Swift is so far superior to Objective C that I switched permanently with version 1.2 three years ago. No more dangling pointers is huge, and worth the toolchain issues.
- anonred 10y ago
  It may be the future, and I love the syntax, but I've run into many of the same problems mentioned in the article (long compile times, SourceKit issues, increase in binary size, etc.) with my own smaller apps. It's honestly frustrating, sometimes more so than the eyesore that is ObjC.
  - melling 10y ago
    Uber and Facebook have large apps. Uber is 500,000 lines of Swift. This means someone is already working on these problems before you get there. The video had a lot of good advice. Hopefully, they'll contribute back to the Swift compiler too.
battwell 10y ago
We were all skeptical about doing a rewrite too. A bunch of us have worked at companies that went through bad rewrites. And we've read https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... :p But the old Uber app had hit its age limit. It was build on top of technology chosen for a small number of features (ex: a single global DI component, lack of typing, a small MVC hierarchy). So we either needed lots of large migrations or a rewrite. The incremental migrations required to fix these issues would have been extremely disruptive, they wouldn't have gotten us an entirely refreshed UI and they wouldn't have given us a number of other benefits. So we decided to do a rewrite. We had lots of engineers that knew the issues to watch for from the first time we wrote the app. And a handful of us spent months researching/building different architectures, static analysis and tooling that would ensure the rewrites success. We weren't going to repeat the same mistakes twice. On the very first day the app launched it was more reliable and performant than the version of our app that we had been maintaining for years.
- beaconstudios 10y ago
  I did assume that in your case the rewrite was valid - after all, you laid out the case. I was just surprised that it went as well as it did - I've seen so many rebuilds that went to shit that it was a genuine shock to see one go well.
  - uberengineer 10y ago
    While I can't speak for mobile rewrites, many systems at Uber have been rewritten several times as the business needs have changed and we've grown in scale. With each iteration the systems become more general and support a greater scale and a greater variety of business needs. The added complexity of our micro-services architecture has been worthwhile because it's reduced the complexity of making changes to systems that can't be taken offline because they are part of the core trip flow. Basically, it's as if we started with a small glider years ago and have upgraded it into a 777 Dreamliner piece by piece while still flying. We have also taken advantage of the rewrites to rebuild in Go and Java. Most of our older systems were NodeJS and Python. Many of those have been rewritten in the two languages we've now mostly standardized on. Pretty much every rewrite I have witnessed has gone well, so I can only guess there's something we're doing right in this respect.

melling 10y ago

Problems aside, Swift is the future of the Apple platform. It's a much less verbose language than Objective C. (no headers, type inference, no @, no ;) https://h4labs.wordpress.com/2016/02/09/should-i-use-objective-c-or-swift-for-writing-ios-apps/ https://h4labs.wordpress.com/2016/02/09/should-i-use-objecti...

beaconstudios 10y ago
my point is that a full switch-over is usually a terrible idea. I don't know if an incremental change-over from ObjC to Swift is possible in the Apple ecosystem, but if it is that's almost always the better option in my experience.
- valuearb 10y ago
  Swift is so far superior to Objective C that I switched permanently with version 1.2 three years ago. No more dangling pointers is huge, and worth the toolchain issues.
anonred 10y ago
It may be the future, and I love the syntax, but I've run into many of the same problems mentioned in the article (long compile times, SourceKit issues, increase in binary size, etc.) with my own smaller apps. It's honestly frustrating, sometimes more so than the eyesore that is ObjC.
- melling 10y ago
  Uber and Facebook have large apps. Uber is 500,000 lines of Swift. This means someone is already working on these problems before you get there. The video had a lot of good advice. Hopefully, they'll contribute back to the Swift compiler too.

battwell 10y ago

We were all skeptical about doing a rewrite too. A bunch of us have worked at companies that went through bad rewrites. And we've read https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... :p But the old Uber app had hit its age limit. It was build on top of technology chosen for a small number of features (ex: a single global DI component, lack of typing, a small MVC hierarchy). So we either needed lots of large migrations or a rewrite. The incremental migrations required to fix these issues would have been extremely disruptive, they wouldn't have gotten us an entirely refreshed UI and they wouldn't have given us a number of other benefits. So we decided to do a rewrite. We had lots of engineers that knew the issues to watch for from the first time we wrote the app. And a handful of us spent months researching/building different architectures, static analysis and tooling that would ensure the rewrites success. We weren't going to repeat the same mistakes twice. On the very first day the app launched it was more reliable and performant than the version of our app that we had been maintaining for years.

beaconstudios 10y ago
I did assume that in your case the rewrite was valid - after all, you laid out the case. I was just surprised that it went as well as it did - I've seen so many rebuilds that went to shit that it was a genuine shock to see one go well.
- uberengineer 10y ago
  While I can't speak for mobile rewrites, many systems at Uber have been rewritten several times as the business needs have changed and we've grown in scale. With each iteration the systems become more general and support a greater scale and a greater variety of business needs. The added complexity of our micro-services architecture has been worthwhile because it's reduced the complexity of making changes to systems that can't be taken offline because they are part of the core trip flow. Basically, it's as if we started with a small glider years ago and have upgraded it into a 777 Dreamliner piece by piece while still flying. We have also taken advantage of the rewrites to rebuild in Go and Java. Most of our older systems were NodeJS and Python. Many of those have been rewritten in the two languages we've now mostly standardized on. Pretty much every rewrite I have witnessed has gone well, so I can only guess there's something we're doing right in this respect.