4 ms·

For ios : look at the number of various apis you can use to do widget positionning and animations : calayer, uiview spring n struts, constraints, physic based,

by bsaul 9y ago

For ios : look at the number of various apis you can use to do widget positionning and animations : calayer, uiview spring n struts, constraints, physic based, and yet none compose well with each other. IOS also doesn't have any good tech for offline storage ( core data should be burried once and for all) and swift relies on compile-time codegen hack to provide easy struct serialization, because techs like nscoding relied on obj-c runtime facilities and the language itself doesn't provide enough metaprogramming facilities to compensate. Also, patterns like KVO are still found from time to time as a last resort in frameworks, while being famously unsafe and still rely on the obj-c runtime. For android basically everything should be rewritten from scratch. Last time i managed a team of android developpers, we basically came to the conclusion that doing regular mvc while supporting a good market share meant recoding our own controller base classes and screen transitionning apis.

_delirium 9y ago
It also doesn't help that these APIs are rapidly changing, in ways ranging from minor rearrangements that the XCode auto-upgrader can mostly handle, to real porting hassles. I've been working on a project that was started in early 2016, so it was originally in Swift 2, the then-current version. A ton of things changed for Swift 3, which came out 6 months later, in late 2016. And a bunch of things are changing again with Swift 4 (although not as many as in the 2->3 upgrade). I haven't yet looked into Swift 5, but presumably that brings yet more API changes. A lot of time is spent just on this treadmill of porting previously working things to modified APIs. To make it worse, you have to manage a 4-way compatibility matrix between Swift versions, XCode versions, iOS versions, and macOS versions, where only very specific combinations work.
- k-mcgrady 9y ago
  AFAIK Swift 3 was supposed to be the last version to introduce breaking changes. Have they changed that policy? I know that the last Swift update I did was very manageable compared to in the past (where I'd easily lose a day or two).
  - _delirium 9y ago
    This project's still on Swift 3, so I don't have first-hand experience upgrading to Swift 4. It looks like there are breaking changes though, albeit not nearly as many as 3 had. The most notable one looks like in the String API [1]. There are a few other minor ones that most projects won't hit, like in the dictionary/set API [2]. A few of these are also slightly more breaking than it initially seems because they've added temporary compatibility workarounds marked as deprecated in Swift 4 to avoid breaking as much working Swift 3 code, but these will go away for Swift 5, so you do still have to port anyway (just not immediately). [1] https://github.com/apple/swift-evolution/blob/master/proposals/0163-string-revision-1.md#source-compatibility https://github.com/apple/swift-evolution/blob/master/proposa... [2] https://github.com/apple/swift-evolution/blob/master/proposals/0165-dict.md#source-compatibility https://github.com/apple/swift-evolution/blob/master/proposa...
  - Tanegashima 9y ago
    Nope. However, Swift 4 is very close to Swift 3 for the most part and the source migrator should work for the most menial transformations.
k-mcgrady 9y ago
>> For ios : look at the number of various apis you can use to do widget positionning and animations : calayer, uiview spring n struts, constraints, physic based, and yet none compose well with each other. IOS also doesn't have any good tech for offline storage ( core data should be burried once and for all) I disagree with most of this. Laying out views was a mess for a while but auto layout is easy to get right once you understand the fundamentals (especially when used in storyboards). Springs and struts is old pre-autolayout tech which shouldn't be used. CALayer is the lower level object that UIView is based on. Not sure what the complaint is here (they're mostly unrelated to autolayout/springs and struts). As for CoreData it's a pretty simple way to manage your data. When originally introduced to iOS it was a mess but I've used it extensively in the last few years, first through a higher level framework (MagicRecord I think?) and now directly and it providing you exercise some care around threading it performs very well, especially for something simple like offline data storage.
- jakeva 9y ago
  As a ten year vet of Cocoa and Cocoa touch, I agree with your counterpoints. A lot of stuff is simply legacy.
- bsaul 9y ago
  Ever tried to have 60fps on a tableview with constraint-based layout cells ? CALayer is definitely not legacy, it's often the only way to get smooth animation. Spring n struts is also sometimes the best way to get fast position for smooth scrolling. Ever had to deal with Core Data migration on an app that needs to evolve throughout the year ? Migration is a mess, and so is concurrency. My personal conclusion after having used Core Data on a pro application for 4 years, is that most of the time i really don't need a database and so i'm back to file-based backups for my app's data. Works well, no magic, and no performance or threading issue.
  - saagarjha 9y ago
    > Ever tried to have 60fps on a tableview with constraint-based layout cells Yes. I've found AutoLayout to be acceptable in this case, provided you're not doing something awful.
zackmorris 9y ago
Also Apple uses a lot of patterns that lead to goto hell because of NeXT's foundations in the delegate pattern: https://en.wikipedia.org/wiki/Delegation_pattern https://en.wikipedia.org/wiki/Delegation_pattern So you start some sequence (like a new UIViewController) and interact with it via callback events instead of having a single (blocking) thread of execution that waits for the view controller call to return like a function. This makes it virtually impossible to deterministically model flow control. Note that since Android copied many metaphors from iOS, it also inherited these complexities in things like its Activity class. I agree that Core Data probably needs to go away (at least its iCloud integration) and be replaced by Firebase or PouchDB etc. KVO was a great missed opportunity because it's not clear who is watching a value. I think the pattern itself has merit from a functional programming perspective (after all this is how Excel works). I generally avoid native mobile development now for these reasons among many, not to mention cross-platform issues. We likely need web metaphors running above native code, writing plugs where necessary (like Cordova or React Native). These are generally quite painful to use though, so I don't see many solutions materializing for at least several more years.
- throwaway91111 9y ago
  I don't think that Core Data is that bad for local storage; it's basically just an ORM.
- coldtea 9y ago
  >So you start some sequence (like a new UIViewController) and interact with it via callback events instead of having a single (blocking) thread of execution that waits for the view controller call to return like a function. This makes it virtually impossible to deterministically model flow control. Why on earth would you have a single blocking thread on a UI app?
  - zackmorris 9y ago
    What I was trying to say is that in the olden days of say the 80s, Mac OS used cooperative threads and you just wrote a main loop that was completely self-contained. We made OS calls from there, the OS didn't call us with events like it does today (at least most of the time). So programs were much simpler to debug because we didn't have callback or goto hell. The tradeoff was that it took pages of boilerplate to make even the simplest app, and Apple got made fun of incessantly for it. So they largely fixed that with OS X's message passing metaphors, but unfortunately due to bloat and a lot of other reasons, the boilerplate issue came back, and now we're also stuck with untraceable program flow. To answer the original question - I have worked on both blocking and nonblocking code, and unfortunately nonblocking code doesn't scale. It eventually becomes too complex to follow the flow. It's like comparing a coroutine to a state machine. My personal feeling is that we're in a kind of nonblocking bubble right now and that the callback style that pretty much all frameworks use today is not going to be the way it's done in the future. I don't know what will replace it, but it will likely be something more like Redux/Elm/Clojure and declarative GUI syntax like how the web used to work.
ClassyJacket 9y ago
For me it feels like the messaging is pretty clear: use AutoLayout. Springs and struts aren't used anymore, constraints are just a part of how AutoLayout works, and I'm not even sure what you mean by physic based.
- myko 9y ago
  I assumed they were talking about UIDynamics (https://www.bignerdranch.com/blog/uidynamics-in-swift/ https://www.bignerdranch.com/blog/uidynamics-in-swift/)
jernfrost 9y ago
I don't see why keyed archiver wouldn't work with swift. I've implemented identical systems in C++ with no dynamic features. Or you can just use JSON serialization for offline storage. I pretty much never use core data. Don't get why people use it so much. On iOS you are a single user of your data so you can easly rely on a combination of plain files for storage. I've seen how Java devs go crazy using core data to just store a few hundred bytes of data. I think people overcomplicate storage 90% of the time.
- bsaul 9y ago
  Keyed archiver doesn't work with structs, and it also probably doesn't work whenevr you start nesting classes. It relies on introspection and dynamic typing for that, which can't work right now with swift. It's one reason they had to rely on compile-time codegen to implement the swift4 equivalent.

by bsaul 9y ago

_delirium 9y ago

It also doesn't help that these APIs are rapidly changing, in ways ranging from minor rearrangements that the XCode auto-upgrader can mostly handle, to real porting hassles. I've been working on a project that was started in early 2016, so it was originally in Swift 2, the then-current version. A ton of things changed for Swift 3, which came out 6 months later, in late 2016. And a bunch of things are changing again with Swift 4 (although not as many as in the 2->3 upgrade). I haven't yet looked into Swift 5, but presumably that brings yet more API changes. A lot of time is spent just on this treadmill of porting previously working things to modified APIs. To make it worse, you have to manage a 4-way compatibility matrix between Swift versions, XCode versions, iOS versions, and macOS versions, where only very specific combinations work.

k-mcgrady 9y ago
AFAIK Swift 3 was supposed to be the last version to introduce breaking changes. Have they changed that policy? I know that the last Swift update I did was very manageable compared to in the past (where I'd easily lose a day or two).
- _delirium 9y ago
  This project's still on Swift 3, so I don't have first-hand experience upgrading to Swift 4. It looks like there are breaking changes though, albeit not nearly as many as 3 had. The most notable one looks like in the String API [1]. There are a few other minor ones that most projects won't hit, like in the dictionary/set API [2]. A few of these are also slightly more breaking than it initially seems because they've added temporary compatibility workarounds marked as deprecated in Swift 4 to avoid breaking as much working Swift 3 code, but these will go away for Swift 5, so you do still have to port anyway (just not immediately). [1] https://github.com/apple/swift-evolution/blob/master/proposals/0163-string-revision-1.md#source-compatibility https://github.com/apple/swift-evolution/blob/master/proposa... [2] https://github.com/apple/swift-evolution/blob/master/proposals/0165-dict.md#source-compatibility https://github.com/apple/swift-evolution/blob/master/proposa...
- Tanegashima 9y ago
  Nope. However, Swift 4 is very close to Swift 3 for the most part and the source migrator should work for the most menial transformations.

k-mcgrady 9y ago

>> For ios : look at the number of various apis you can use to do widget positionning and animations : calayer, uiview spring n struts, constraints, physic based, and yet none compose well with each other. IOS also doesn't have any good tech for offline storage ( core data should be burried once and for all) I disagree with most of this. Laying out views was a mess for a while but auto layout is easy to get right once you understand the fundamentals (especially when used in storyboards). Springs and struts is old pre-autolayout tech which shouldn't be used. CALayer is the lower level object that UIView is based on. Not sure what the complaint is here (they're mostly unrelated to autolayout/springs and struts). As for CoreData it's a pretty simple way to manage your data. When originally introduced to iOS it was a mess but I've used it extensively in the last few years, first through a higher level framework (MagicRecord I think?) and now directly and it providing you exercise some care around threading it performs very well, especially for something simple like offline data storage.

jakeva 9y ago
As a ten year vet of Cocoa and Cocoa touch, I agree with your counterpoints. A lot of stuff is simply legacy.
bsaul 9y ago
Ever tried to have 60fps on a tableview with constraint-based layout cells ? CALayer is definitely not legacy, it's often the only way to get smooth animation. Spring n struts is also sometimes the best way to get fast position for smooth scrolling. Ever had to deal with Core Data migration on an app that needs to evolve throughout the year ? Migration is a mess, and so is concurrency. My personal conclusion after having used Core Data on a pro application for 4 years, is that most of the time i really don't need a database and so i'm back to file-based backups for my app's data. Works well, no magic, and no performance or threading issue.
- saagarjha 9y ago
  > Ever tried to have 60fps on a tableview with constraint-based layout cells Yes. I've found AutoLayout to be acceptable in this case, provided you're not doing something awful.

zackmorris 9y ago

Also Apple uses a lot of patterns that lead to goto hell because of NeXT's foundations in the delegate pattern: https://en.wikipedia.org/wiki/Delegation_pattern https://en.wikipedia.org/wiki/Delegation_pattern So you start some sequence (like a new UIViewController) and interact with it via callback events instead of having a single (blocking) thread of execution that waits for the view controller call to return like a function. This makes it virtually impossible to deterministically model flow control. Note that since Android copied many metaphors from iOS, it also inherited these complexities in things like its Activity class. I agree that Core Data probably needs to go away (at least its iCloud integration) and be replaced by Firebase or PouchDB etc. KVO was a great missed opportunity because it's not clear who is watching a value. I think the pattern itself has merit from a functional programming perspective (after all this is how Excel works). I generally avoid native mobile development now for these reasons among many, not to mention cross-platform issues. We likely need web metaphors running above native code, writing plugs where necessary (like Cordova or React Native). These are generally quite painful to use though, so I don't see many solutions materializing for at least several more years.

throwaway91111 9y ago
I don't think that Core Data is that bad for local storage; it's basically just an ORM.
coldtea 9y ago
>So you start some sequence (like a new UIViewController) and interact with it via callback events instead of having a single (blocking) thread of execution that waits for the view controller call to return like a function. This makes it virtually impossible to deterministically model flow control. Why on earth would you have a single blocking thread on a UI app?
- zackmorris 9y ago
  What I was trying to say is that in the olden days of say the 80s, Mac OS used cooperative threads and you just wrote a main loop that was completely self-contained. We made OS calls from there, the OS didn't call us with events like it does today (at least most of the time). So programs were much simpler to debug because we didn't have callback or goto hell. The tradeoff was that it took pages of boilerplate to make even the simplest app, and Apple got made fun of incessantly for it. So they largely fixed that with OS X's message passing metaphors, but unfortunately due to bloat and a lot of other reasons, the boilerplate issue came back, and now we're also stuck with untraceable program flow. To answer the original question - I have worked on both blocking and nonblocking code, and unfortunately nonblocking code doesn't scale. It eventually becomes too complex to follow the flow. It's like comparing a coroutine to a state machine. My personal feeling is that we're in a kind of nonblocking bubble right now and that the callback style that pretty much all frameworks use today is not going to be the way it's done in the future. I don't know what will replace it, but it will likely be something more like Redux/Elm/Clojure and declarative GUI syntax like how the web used to work.

ClassyJacket 9y ago

For me it feels like the messaging is pretty clear: use AutoLayout. Springs and struts aren't used anymore, constraints are just a part of how AutoLayout works, and I'm not even sure what you mean by physic based.

myko 9y ago
I assumed they were talking about UIDynamics (https://www.bignerdranch.com/blog/uidynamics-in-swift/ https://www.bignerdranch.com/blog/uidynamics-in-swift/)

jernfrost 9y ago

I don't see why keyed archiver wouldn't work with swift. I've implemented identical systems in C++ with no dynamic features. Or you can just use JSON serialization for offline storage. I pretty much never use core data. Don't get why people use it so much. On iOS you are a single user of your data so you can easly rely on a combination of plain files for storage. I've seen how Java devs go crazy using core data to just store a few hundred bytes of data. I think people overcomplicate storage 90% of the time.

bsaul 9y ago
Keyed archiver doesn't work with structs, and it also probably doesn't work whenevr you start nesting classes. It relies on introspection and dynamic typing for that, which can't work right now with swift. It's one reason they had to rely on compile-time codegen to implement the swift4 equivalent.