Live data from Hacker News

Swift 5: start your engines

lists.swift.org

111–120 of 186 posts

Re: Swift 5: start your engines

#111
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…

I'd use react-native if I were you. I think you'd pick up Swift pretty easily given your polyglot background, but if you already know javascript and you aren't doing something that screams to be native, RN would be my choice. You'll get to work in a familiar language, and get an Android version with much less work than if you do swift. Best resource to start a react native app I'd say is this, it was really easy for…

Don’t use React Native.

There is little “native” about React Native. It’s something web “devs” like to convince themselves because they don’t know better.

Using merely UIView objects does not mean it is native. It’s not just an abstraction over native. The “great” minds at Facebook have decided to not only offer a JS wrapper around the native APIs and objects, but actually reinvent the wheel on everything. Tables? Let’s have a horrible implementation in JS. Gestures? Slow ones in JS. Navigation? Absolutely terrible in JS. Animations? Core Animation you say? Nope, in JS or in C++. Even simple stuff like buttons are not native UIButton objects. There is nothing “native” in React Native.

Also, the single threaded model of JS just does not scale. The larger the app gets, the more and more it starts to lag. UI is rendering at 60 FPS, sure, but the lag comes from a constantly busy single JS thread.

And that’s before mentioning things like accessibility, large type support, basic iOS concepts such as margins and layout guides, etc. that are sorely missing from RN.

Re: Swift 5: start your engines

#112
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…

I'm surprised no one has mentioned this but I'd say the #1 resource for learning the practical 'how do I get X thing done in a couple of hours' are tutorials on https://www.raywenderlich.com/ without a doubt. It has tutorials for every basic question imaginable in a very easy to follow manner. It'll definitely take some time, as for being enjoyable - I don't get a kick out of learning an entire new set of libraries a…

Ray Wanderlich tutorials are good quality, but I don’t really like the way he writes.

I recommend to look at this site, he’s a really “clean” teacher

https://www.hackingwithswift.com/

Re: Swift 5: start your engines

#113

Earlier quoted context omitted.

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

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).

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.

Re: Swift 5: start your engines

#114
post #54
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…

Hardest part isn'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). Stanford courses are the best you can find online for free. https://youtu.be/HitSIzPM_6E

Languages are easy. It's always the frameworks (which are usually needed for any real world tasks) that are the killer.

Re: Swift 5: start your engines

#115
post #104

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…

> 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.

Re: Swift 5: start your engines

#116
post #49

About concurrency : does anyone know of a language that would let you tag portions of a codebase in some way, and declare something like "all those methods should execute in the same thread". Those declarations would then be checked by the compiler. That would be a first step toward agent like concurrency, but it would be general enough to apply to other types of concurrency models.

Ugh, makes me think of COM

https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...

Re: Swift 5: start your engines

#117
post #104

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…

> Ever tried to have 60fps on a tableview with constraint-based layout cells ?

Yes, even on a 4S.

Re: Swift 5: start your engines

#118
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…

I'd use react-native if I were you. I think you'd pick up Swift pretty easily given your polyglot background, but if you already know javascript and you aren't doing something that screams to be native, RN would be my choice. You'll get to work in a familiar language, and get an Android version with much less work than if you do swift. Best resource to start a react native app I'd say is this, it was really easy for…

“I want to learn how to fly a Cessna where should I start?”

“I’d recommend hang gliding. That way, you don’t have to worry about the complexities of piston engines. Since you already know how to fly a kite, you’re practically there already.”

While hang gliders and Cessnas are both flying, there are a lot of things Cessna can do that hang gliders can’t.

I will be glad when JavaScript stops being the answer to every question. iOS apps aren’t just webpages running on a phone. How, for example, does react handle pre-release Apple APIs? How does it work with ARKit or other iOS specific tech?

Why do we insist on building to quite literally the lowest common denominator rather than building to the strengths of iOS and Android?

React Native could be a prudent choice for certain kinds of apps, but I’d argue that the apps for which React Native excels probably don’t need to be apps in the first place.

Apps ought not be glorified web pages; they should take advantage of the hardware to the fullest extent.

If an actual Swift developer recommends React Native, I might listen, but generally it’s web developers who downplay the advantages of Swift because they themselves have been unwilling to learn how to get the most out of it and the iOS APIs.

This whole cross-platform obsession results in lower quality applications. Case in point: Slack for Mac OS. It’s decent, but it would be significantly better if it were actually native. This trend of wrapping a webpage and calling it an app is a disservice to your customers.

There’s a reason I have an iPhone. Yet, with this cross-platform nonsense, developers are essentially kneecapping our devices. This applies to Android as well.

Re: Swift 5: start your engines

#119

Earlier quoted context omitted.

This cliche statement feels trite for such a large project. I'd understand it for a 1000 line JS library, but it makes no sense for a complex language ecosystem that requires multiple full time engineers to maintain.

It isn't my intention to sound "trite". I've personally contributed a little bit to Swift. You don't have to be a compiler genius to help out - you can contribute to Swift Foundation which is almost entirely Swift code and would directly improve cross-platform support. I would also note that saying "I wish more effort were being made" is a bit entitled when you're talking about an open source project. No one working…

> I would also note that saying "I wish more effort were being made" is a bit entitled when you're talking about an open source project. No one working on any open source project owes you anything.

no, "i wish" just means "i wish". it doesn't imply anything like "being owed".

being "open source" doesn't establish carte blanche to oblige everyone to labor on the project if they dared to have a thought or opinion.

> If you want the project to get better then find a way to contribute.

there are thousands of projects i'd like to see get better. not everyone has the time, ability, desire or capacity to implement everything they've ever wished for. this is just silly.

Re: Swift 5: start your engines

#120
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…

I'm surprised no one has mentioned this but I'd say the #1 resource for learning the practical 'how do I get X thing done in a couple of hours' are tutorials on https://www.raywenderlich.com/ without a doubt. It has tutorials for every basic question imaginable in a very easy to follow manner. It'll definitely take some time, as for being enjoyable - I don't get a kick out of learning an entire new set of libraries a…

> One last thing - the amount of information for macOS is about 1% compared to iOS, so I'd definitely go the iOS route.

I thought that too, but it’s not accurate at all, from recent experience. There is a lot of hidden treasure for macOS, but it is buried under layers of bad Google results because somehow “NSViewController” makes Google shows me results for “UIAppDelegate” and “UIView”—makes sense. A lot of information is out there, on SO, Apple developer forums and mailing lists.

Post reply on HN