Live data from Hacker News

Ask HN: What do you regret you didn't know when programming for iOS or Android?

news.ycombinator.com

111–120 of 166 posts

Re: Ask HN: What do you regret you didn't know when programming for iOS or Android?

#111
post #107

Earlier quoted context omitted.

Personally I think that Flutter is the future for cross-platform UI toolkits. As a React dev (in my spare time, I’m still a student), using RN was a pain due to the need to install native extensions for almost everything. The batteries-included approach of Flutter and just the polish around the dev workflow made it more attractive to a beginner mobile dev.

Flutter is DOA for anything but short-term projects. For one thing, it’s tied to a custom language. That means there’s significant overhead for developers which shows itself directly as a learning curve, or indirectly in terms of hiring or retention of developers. At least as significantly, they chose to implement custom controls (rather than wrap native controls). With that approach there’s really no way for them to…

> For one thing, it’s tied to a custom language.

Are you talking about Dart?

If so, that's absolutely savage, lmao. To not only call it a "custom" language but not even name it. The amount of disrespect - and the worst thing is I don't even think it was intended. Even if this is one person, I think this speaks volumes about how much of a joke the language is.

It's just so sad. And to think that the team behind flutter purposefully chose it after considering a bunch of other languages.

Re: Ask HN: What do you regret you didn't know when programming for iOS or Android?

#112
post #107

Earlier quoted context omitted.

Personally I think that Flutter is the future for cross-platform UI toolkits. As a React dev (in my spare time, I’m still a student), using RN was a pain due to the need to install native extensions for almost everything. The batteries-included approach of Flutter and just the polish around the dev workflow made it more attractive to a beginner mobile dev.

Flutter is DOA for anything but short-term projects. For one thing, it’s tied to a custom language. That means there’s significant overhead for developers which shows itself directly as a learning curve, or indirectly in terms of hiring or retention of developers. At least as significantly, they chose to implement custom controls (rather than wrap native controls). With that approach there’s really no way for them to…

I disagree strongly with this.

I'm currently writing a cross-platform app in Flutter that is launching soon, and I found that the developer experience is world-class and I've had very few issues so far. The language is incredibly easy to pick up with close to zero overhead if you are a somewhat competent programmer as it is essentially a very lightweight OOP language. My main languages are otherwise Go and Rust, and picking up Dart was not difficult at all for me and I don't think you need to be a wizard to figure it out. I suspect JS devs will find it even easier to pick up as many of the constructs are similar.

It took only a couple of days to get up to speed with Flutter-specific functionality as well as the native API bindings, and I was already writing production code for the app the first week of exposure to the language. The UI framework is declarative and very easy to reason about and design, and the tooling is also incredibly seamless and easy to use, although I do agree that it needs some polishing as there are some edge cases that you sometimes need to trawl the Github issues page to fix.

Yes, sometimes it is frustrating as there are some things that are lacking in the standard library, but the third-party library scene is picking up and you can do 95% of what you want to do without major issue. I'm convinced that Flutter is going to become bigger in the future and is going to cover most use cases for all but the most performant apps and perhaps games.

Re: Ask HN: What do you regret you didn't know when programming for iOS or Android?

#113
post #108
post #95

Earlier quoted context omitted.

I think you'd indeed have to look at more demanding applications, more "bleeding edge" stuff computationally: 3D gaming is probably as good a candidate as ever, maybe some in-app AI workflows, idk. Truth is, I know how to bring a desktop/server to its knees because there are valid use-cases for that, but on mobile I struggle to find many examples indeed. I guess any heavy data crunching app might fit the bill, but wh…

The issues you tend to run into with mobile is that you have to either create so many shim layers to use native app features or resort to 3rd party solutions. And there are loads of examples (speaking for iOS here): 1. JSON parsing 2. Network calls 3. Background downloading 4. Notifications 5. Camera access 6. Password/contact/code auto fill 7. VoiceOver 8. Web Views 9. JavaScript bridging 10. Encryption 11. And many…

> “It’s why at this point I refuse to do anything but native in my career.”

Point well taken! If I may ask, would you say that

1. it's a problem inherent to developing on mobile (whatever the underlying reasons, hardware iterations, idk), and that OS APIs are indeed trying to solve as best they can (it's just a hard problem),

or rather

2. that it's a problem somehow created by OS vendors of their own volition? (a.k.a "evil microsoft walled garden", cue "Apple's take on that" and Google's similar moves for Android and we think Fuschia) In essence a business-driven reality.

I actually don't care about "evil" (hence the wording, it's funny) when it's just business strategy; my deeper question is really about the problem space.

Like, is this forever (native versus cross on a fast-iterating platform), is this industrial politics or technical limitations, could some other platform do it "better" (thinking of SailfishOS, or the Linux phones like the Pine project etc.)

Re: Ask HN: What do you regret you didn't know when programming for iOS or Android?

#115
post #92

Earlier quoted context omitted.

This is a nit, but there's a pretty big difference between refactoring and rearchitecting. If you plan for an eventual migration of the app from a cross-platform toolkit to native, then often you're committing to a significant rewrite of the app. This means either you dedicate a team to the rewrite or you stop adding features while it gets rewritten. Plus it will take a while for the native version to get feature par…

> “I'm sure there are tools and strategies for getting this right, but I've seen this basically kill startups.” Well if they're doing it like that, it's indeed not much better than hara-kiri. There are better ways :) How you do it is incrementally, avoiding too-major changes at once, and progressively moving from codebase A (cross-platform framework) towards codebase B (new native thing). But it happens at the integr…

Make sense. And may be should start with this thinking when I started to avoid the first pain.

Re: Ask HN: What do you regret you didn't know when programming for iOS or Android?

#116
post #10

Earlier quoted context omitted.

> Don’t get me wrong, iOS is great, and I love it to death. However, the baggage signals to me that a massive opportunity to start anew has been missed. I guess that's what Flutter is doing (for both iOS and Android).

> I guess that's what Flutter is doing (for both iOS and Android). How does it do this as opposed to adding yet one more layer? Does it somehow get beneath all the cruft mentioned?

Besides being a cross platform platform for Android and iOS, it appears to be a native UI framework for Fuchsia, Google’s nearly ‘from scratch’ OS.

Re: Ask HN: What do you regret you didn't know when programming for iOS or Android?

#118
post #59

I wish I would have not fought the tools so much. I started Android programming from the command line using make/ant and testing on a device because I didn't like Android Studio. This ended up wasting a lot of time and energy over the years as I had to integrate more 3rd party libraries (including Google's own crap). Same thing for iOS. I didn't like building GUIs in Interface Builder so I did everything in code. Ove…

Code-only purists are still prominent in the iOS community. Yeah, there’s definitely baggage one must take on when using IB but the ease of being able to instantly preview your layout in different sizes is the big seller for me.

IB files are essentially impossible to code review.

Re: Ask HN: What do you regret you didn't know when programming for iOS or Android?

#119
post #107

Earlier quoted context omitted.

Flutter is DOA for anything but short-term projects. For one thing, it’s tied to a custom language. That means there’s significant overhead for developers which shows itself directly as a learning curve, or indirectly in terms of hiring or retention of developers. At least as significantly, they chose to implement custom controls (rather than wrap native controls). With that approach there’s really no way for them to…

> For one thing, it’s tied to a custom language. Are you talking about Dart? If so, that's absolutely savage, lmao. To not only call it a "custom" language but not even name it. The amount of disrespect - and the worst thing is I don't even think it was intended. Even if this is one person, I think this speaks volumes about how much of a joke the language is. It's just so sad. And to think that the team behind flutte…

I don't think he meant it that way. He's probably trying to say that depending on a "custom language" is a bad thing in itself.

I personally don't feel that dart is tied in any way to flutter. It was originally meant to be compiled to js, and that shows in vm architecture, but that doesn't look like a con.

Re: Ask HN: What do you regret you didn't know when programming for iOS or Android?

#120
If you think you will ever be cross platform, do yourself a favor and write as much of the business logic as you can in C++ or C. The platform-specific piece should be small and “just enough to make the platform happy”. Do everything else portably from the start.
Post reply on HN