<story><title>Swift 5: start your engines</title><url>https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170807/038645.html</url></story><parent_chain><item><author>bsaul</author><text>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&amp;#x27;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&amp;#x27;t provide enough metaprogramming facilities to compensate.&lt;p&gt;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.&lt;p&gt;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.</text></item><item><author>bogomipz</author><text>&amp;gt;&amp;quot;IOS sdk, on the other hand, has become a bit of a mess, due largely to the pace at which the field is moving ( although not as bad as android).&amp;quot;&lt;p&gt;Could you elaborate on whats messy with these SDKs?</text></item><item><author>bsaul</author><text>Hardest part isn&amp;#x27;t the language. Swift is among the best languages you can get today. IOS sdk, on the other hand, has become a bit of a mess, due largely to the pace at which the field is moving ( although not as bad as android).&lt;p&gt;Stanford courses are the best you can find online for free. &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;youtu.be&amp;#x2F;HitSIzPM_6E&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;youtu.be&amp;#x2F;HitSIzPM_6E&lt;/a&gt;</text></item><item><author>ssijak</author><text>And just today I was contemplating writing my first native iOS and macOS app... I was looking at the options and decided to go native with Swift. I have never written Objective-C app and never used x-code for dev. But I have ~10 years of dev experience, mostly Java and Python on the backend and front end dev exp mostly with Angular. Some Android, and a little from &amp;lt;input_random_tech_here&amp;gt; because I like to experiment.&lt;p&gt;So, my question is. How hard and enjoyable is for someone like me to write not very complex native iOS&amp;#x2F;macOS app in Swift starting from scratch? Best resource to start with?</text></item></parent_chain><comment><author>k-mcgrady</author><text>&amp;gt;&amp;gt; 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&amp;#x27;t have any good tech for offline storage ( core data should be burried once and for all)&lt;p&gt;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&amp;#x27;t be used. CALayer is the lower level object that UIView is based on. Not sure what the complaint is here (they&amp;#x27;re mostly unrelated to autolayout&amp;#x2F;springs and struts).&lt;p&gt;As for CoreData it&amp;#x27;s a pretty simple way to manage your data. When originally introduced to iOS it was a mess but I&amp;#x27;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.</text></comment>
<story><title>Swift 5: start your engines</title><url>https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170807/038645.html</url></story><parent_chain><item><author>bsaul</author><text>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&amp;#x27;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&amp;#x27;t provide enough metaprogramming facilities to compensate.&lt;p&gt;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.&lt;p&gt;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.</text></item><item><author>bogomipz</author><text>&amp;gt;&amp;quot;IOS sdk, on the other hand, has become a bit of a mess, due largely to the pace at which the field is moving ( although not as bad as android).&amp;quot;&lt;p&gt;Could you elaborate on whats messy with these SDKs?</text></item><item><author>bsaul</author><text>Hardest part isn&amp;#x27;t the language. Swift is among the best languages you can get today. IOS sdk, on the other hand, has become a bit of a mess, due largely to the pace at which the field is moving ( although not as bad as android).&lt;p&gt;Stanford courses are the best you can find online for free. &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;youtu.be&amp;#x2F;HitSIzPM_6E&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;youtu.be&amp;#x2F;HitSIzPM_6E&lt;/a&gt;</text></item><item><author>ssijak</author><text>And just today I was contemplating writing my first native iOS and macOS app... I was looking at the options and decided to go native with Swift. I have never written Objective-C app and never used x-code for dev. But I have ~10 years of dev experience, mostly Java and Python on the backend and front end dev exp mostly with Angular. Some Android, and a little from &amp;lt;input_random_tech_here&amp;gt; because I like to experiment.&lt;p&gt;So, my question is. How hard and enjoyable is for someone like me to write not very complex native iOS&amp;#x2F;macOS app in Swift starting from scratch? Best resource to start with?</text></item></parent_chain><comment><author>zackmorris</author><text>Also Apple uses a lot of patterns that lead to goto hell because of NeXT&amp;#x27;s foundations in the delegate pattern:&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Delegation_pattern&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Delegation_pattern&lt;/a&gt;&lt;p&gt;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.&lt;p&gt;I agree that Core Data probably needs to go away (at least its iCloud integration) and be replaced by Firebase or PouchDB etc.&lt;p&gt;KVO was a great missed opportunity because it&amp;#x27;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).&lt;p&gt;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&amp;#x27;t see many solutions materializing for at least several more years.</text></comment>