The tirade against Apple in the middle article is pretty silly. Android OS has a terrible bug that means you can’t listen to your preferred music on your device. iOS does not have this bug. As someone who uses and develops for both OS, this seems like a no-brainer to me.
Seems like both AirBnB and Udacity made the mistake of not investing enough in the tech. If you keep building out full native features while transitioning a brownfield app to RN, you’re going to have this fragmentation problem.
I’ve converted, (with lots of help of course), a massive brownfield platform product to RN. It took a lot of work, building the right bridging layers, retraining the team, figuring out best practice, etc. We still have a lot of tech debt, but it works!
Pros: Solid cross platform development, easy to teach, easy to get up and running on Xcode/Android Studio (running and working on both in first week on the job), easy to teach the native languages from there, real time bug fixes, fast iteration times on new features. Cons: No 64b on Android, Android peformance lags behind iOS, RN bugs, build process was tough to nail down, no built in navigation support.
We’ve now solved most of the huge RN exclusive problems we had with RN we had when we started out, so at this point I’m not going to be abandoning it anytime soon. There are still problems, but just your average engineering problems, same as you’d get in native development land or any other platform. It’s been about 3 years now, with a 10+ person team now, so maybe I should write it all up somewhere.
Did it not before? Of those pros you mentioned, are they worth the many year investment you made and are continuing to make in the tech? Hypothetically, if the tech were to fall out of favor soon, does that change the worthiness?
It doesn’t compile it to JVM, it runs a JS engine, and then passes some calls into the native side over an asynchronous bridge, and the native code then builds native views at runtime. It’s a middle ground, and it’s super useful in some cases, and super dumb in others. It’s not a silver bullet, it doesn’t solve all the problems, but it has some good use cases.
I try to use ObjC PPC macros for things that are constant for the run of the program, and can be reasoned about globally.
For example, some good ones I use are isLandscape or isIPad, which are both variable depending on the user, but constant for the run of the app. Perfect for a PCH file I think.
This is my thought exactly. I've written a few open source Swift components to learn the language, but it's just not ready to work on the scale that mobile software is reaching.
Mobile software development isn't about a developer or two building "apps" anymore, it's grown much bigger than that.
Is this still the case with Swift 4? Swift had lots of issues as of the 2016 wwdc (language changes breaking third party libraries, barely working tools) however swift 4 seems to be not nearly as bad. I’d be interested in hearing your thoughts.
Swift 4 as a language is marvellous. It’s the tooling that’s still very annoying to work with – autocomplete not working, SourceKit burning CPU time, crashes, that kind of thing.
Swift is great for a small app, with a handful of developers. For a platform, which interops with multiple languages, being worked on by a large team of engineers, switching to Swift would just be silly.
Oh yeah, let me increase my compile times, the size of my SDK, add complications for my publishers, see zero performance benefit, build a ton of scaffolding code, add yearly tech debt until Swift is actually a mature stable language. Terrible idea!
It might be the gold standard some day, but for now it's just a kid compared to ObjC, and everything that comes with being a C based language. If you're learning to make apps, by all means, you should learn Swift, but it will be quite a long time before ObjC is dead and gone, so be prepared to learn both young padawan.
Not to mention, the hype train/bandwagon is really muddying the waters. It's probably a bad idea to take advice on how performant/powerful Swift is from a Zealot, or someone that's betting everything on it.
A larger team benefits more from the ability to write higher quality code with Swift. Fewer or no crashes is s better customer benefit than some hypothetical minor performance benefit. The toolchain does suck though, if Apple (or done one else) fixes the toolchain Objective C is done as a viable language.
What it really means is that the market for software language is being exploited and usurped in order to maintain developer mindshare. The only really good reason to learn Swift is "because everyone else is learning it".
The most important, and sufficient, reason to learn Swift - or anything else, for that matter - is curiosity. I don't like working with people who are not curious about their craft.
Its really unnecessary to learn Swift -there are a plethora of other, better ways to build apps.
But if you want to keep up with the joneses - while delivering Apple a perfect 'big stick' to keep developer mindshare locked into their platforms - Swift is a pretty sweet deal .. for Apple.
Well. If you just want to confirm the order you should be calling methods, you should be able to figure out how to use any of those APIs based on Swift examples.
If anything, Swift examples are more necessary because there's tricky things you can do with closures, manp, flatMap, etc.
I find it it strange that you complains seem to be about tooling, yet you start the comment as if Swift - the language - is the problem.
In my experience, Swift has been great, I vastly prefer it to ObjC. What I don't prefer is SourceKit constantly crashing on me for example, but I wouldn't attribute that to Swift.
Mike, this line is completely and 100% inaccurate:
"Private APIs do nothing that a third-party developer couldn't do in their own code, if they knew how to write it."
There are a million things under the sun that private APIs have access to that wouldn't be possible with the use of public APIs alone, good developer or not. Prime example: "UIGetScreenImage()". That function allows you to take a screenshot of the device's entire screen, your app, someone else's app, the home screen of iOS. That's a pretty big security hole, is it not?
There are countless examples just like that one hidden inside the private API bubble. Things the OS needs to function, (although the OS may not need that particular example anymore) but could cause massive security issues.
Well, let's be clear here. I use React Native, and it would take me about 30m to write a bridged React Native method that could execute ObjC code dynamically, including accessing all the private APIs you could want.
Yeah. Objective-C is definitely really flexible. From my reading of the warning, the important thing is not to execute Objective-C dynamically or access private APIs regardless of whether you're using React Native, Cordova, a WebView, or even a bare iOS app.
You definitely will want to write images to file, then pass the file path over the bridge. That's an easy solution.
I've been using React Native cross platform for over a year, and it has a ridiculous number of issues, but they're trade offs. There are benefits that come with it. React Native is just another tool, evaluate it as you would any other framework.
