Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift 5: start your engines

lists.swift.org

Post reply on HN
Print view View original

171–180 of 186 posts

Re: Swift 5: start your engines

#171

Post by jernfrost »

bsaul wrote: post #75
bogomipz wrote: post #64

Earlier quoted context omitted.

>"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)." Could you elaborate on whats messy with these SDKs?

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 r…

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.

Re: Swift 5: start your engines

#172

Post by bsaul »

jernfrost wrote: post #171
bsaul wrote: post #75

Earlier quoted context omitted.

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 r…

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 ju…

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.

Re: Swift 5: start your engines

#173

Post by bsaul »

k-mcgrady wrote: post #162
acmecorps wrote: post #152

Earlier quoted context omitted.

How in the world did you managed to use storyboard? I hate using it for moderate-complex UI apps. This guy say it better than me on why I hate storyboard (especially the first reason): https://www.youtube.com/watch?v=g6yz5oX5iWc FWIW, if you like and good at it, more power to you.

I use it in combination with programmatic UI for more complex things but find it's so much easier and faster when doing auto layout to just use storyboards.

The real reason for which i stopped using them is that it doesn't work well with git. As soon as you've got more than one people in the team, it's over.

Re: Swift 5: start your engines

#175

Post by geodel »

> the Core Team felt that we could strike a balance with not diluting attention from ABI stability while still enabling a broader range of proposals compared to Swift 4 by requiring that all proposals have an implementation before they are officially reviewed by the Core Team.

Good. They are effectively saying 'Talk is cheap, show me the code'

Re: Swift 5: start your engines

#176

Post by samcat116 »

physicsyogi wrote: post #142
ssijak wrote: post #44

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 because I like to experiment. So, my question is. How…

Hacking With Swift is pretty good for learning iOS and Swift. https://www.hackingwithswift.com/

^ can confirm all of the books by Paul are really well written

Re: Swift 5: start your engines

#177

Post by LeoNatan25 »

kartickv wrote: post #156
bogomipz wrote: post #64

Earlier quoted context omitted.

>"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)." Could you elaborate on whats messy with these SDKs?

I found myself wasting months to do something that should have been handled better in iOS. - APIs return non-descriptive error codes like -16405. Some of them aren't documented. And even the ones that are are not found clearly. Different codes are documented in different files. If you don't know where to look, you won't find it. Java-style descriptive error names like InvalidFrameRateException are sorely missing. iOS…

All you describe here is your laziness.

> Common abstractions like

Look at https://cocoacontrols.com

> Even the async APIs are inconsistent

The APIs are consistent conceptually with what the frameworks are doing. Obtaining contacts or calendar events is something you usually want to do on a background queue, while photos you want on a main queue. Besides, I don't understand what the problem is. Is it so difficult cognitively for you to call `dispatch_async` to the main queue?

> Swift doesn't have async/await

Lord have mercy, no async await. How will we ever overcome that, it's soo hard to use GCD. Come on.

> Otherwise, you'll get a prompt for Camera, and before you respond, it disappears and is replaced by a prompt for Photos

This is the worst practice of all. If you bombard your user with permission requests, your app is automatically bad in my book.

> My app would crash

Next time read the documentation, and use the provided API to check for availability of features and permission status.

> In summary, you waste months of your time working around insufficiently-documented iOS issues, or debugging things, or reimplementing common things in every app.

Everything you wrote here is very well documented in Apple doc and headers.

Re: Swift 5: start your engines

#178

Post by LeoNatan25 »

mahyarm wrote: post #158
dep_b wrote: post #154

Earlier quoted context omitted.

I think strings in Swift are primarily meant to be very correct above being fast or easy to use. It's more strict than both Python 2 and 3. Handling of languages that use really complex character compositions springs to mind.

There is no obvious way to turn that off fortunately, when you don't need it.

I think it's coming. Part of the String Manifesto Apple has is that they want to give both worlds.

Re: Swift 5: start your engines

#179

Post by mmargerum »

bsaul wrote: post #104
k-mcgrady wrote: post #83

Earlier quoted context omitted.

>> 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 onc…

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 ha…

I came to the same conclusion WRT core data. I'm caching data myself to files. I would use SQLite directly if I need a real data store before I would use code data again

Re: Swift 5: start your engines

#180

Post by kartickv »

LeoNatan25 wrote: post #177
kartickv wrote: post #156

Earlier quoted context omitted.

I found myself wasting months to do something that should have been handled better in iOS. - APIs return non-descriptive error codes like -16405. Some of them aren't documented. And even the ones that are are not found clearly. Different codes are documented in different files. If you don't know where to look, you won't find it. Java-style descriptive error names like InvalidFrameRateException are sorely missing. iOS…

All you describe here is your laziness. > Common abstractions like Look at https://cocoacontrols.com > Even the async APIs are inconsistent The APIs are consistent conceptually with what the frameworks are doing. Obtaining contacts or calendar events is something you usually want to do on a background queue, while photos you want on a main queue. Besides, I don't understand what the problem is. Is it so difficult cog…

Please be civil and avoid gratuitous negativity, as the HN guidelines say.

There's no need for statements like "you have developed a terrible app" or "You are the type of developer that..."

Post reply on HN