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

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

news.ycombinator.com

Post reply on HN
Print view View original

91–100 of 166 posts

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

#91

Post by georgemcbay »

allo37 wrote: post #69

On Android, that there hasn't been much love for C/C++ and the NDK is full of interesting pitfalls: Oh your camera gives you NV21 frames, but the hardware VP8 encoder only accepts I420? Makes perfect sense. Oh, we don't actually let you query what format the encoder expects until a later API than you're using. Just try them in a loop until one doesn't fail, makes perfect sense. The camera was a party too, added a lis…

The Android camera issues you reference reached all the way up to the higher level Java APIs, at least back when I was doing Android development from 2012 until about a year ago. Dunno if it has gotten any better since then.

All of the MediaCodec APIs were quite powerful, but did nothing to "keep the easy things easy" or hide much of the lower level hardware details from your app.

This is kind of a theme in Android (or was... my experience is slightly out of date right now).

As mentioned by "McDev" in what is currently the top post on this thread it is a good idea to use time-tested third party libraries to do things that you'd kinda expect the OS to handle naively because the OS level APIs don't do a great job at abstracting any of the details away even for things that you'd think you shouldn't have to worry about, like basic image loading with caching and resizing. And that's just still images, never mind when you get into video de/compression.

Hopefully this is something the Android team is working on as they shift more effort toward Kotlin and Jetpack but I haven't had enough recent hands-on experience to know if this is better now.

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

#92

Post by K0SM0S »

SquishyPanda23 wrote: post #89
freehunter wrote: post #73

Earlier quoted context omitted.

On the other hand, very few applications need to scale to the point where it matters. If the options are "ship something now and refactor later" versus "ship something in six months that's perfect but too late", most people here would benefit from cross platform solutions. Very few companies have ever failed because their tech stack didn't scale well.

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 integration level, i.e. you build with increasingly more % from B, but during the whole A->B transition it'll be a hybrid build.

E.g. part Flutter / part native.

1. You begin with "let's take camera stuff out of Flutter and re-implement our related features using native APIs": this instantly makes two apps (iOS, Android) with 90-99% code in common, just a fork to handle camera APIs separately (by the way, the state of API affairs often forced you to do this to some extent for any non-trivial use-case; I'd wager it used to be the state of most feature-rich apps in the 2010s).

2. Then you proceed with another component of your app. Rinse and repeat until you've got 90% from B and the remaining stuff is structural.

3. All that remains is to remove Flutter entirely from the equation and rewrite your core app logic: what glues all of the above components together; all of which at that stage are already rewritten for native and tested independently (critical to your success).

Along the way you never truly break UX, it's more of a classic "ongoing development" thing with details changing here and there, and hopefully better UX each step since your move to native must be motivated by something worth it for the client-side (otherwise it's likely your server API model that needs refactoring).

That's how the now-default-consensual approach to how you change stacks without breaking UX, nor your company. Full rewrites on wholly new tech is just asking for cataclysm: you literally do that to yourself, to your own code and users. It's also the only reasonable way I know for small teams, one-man shows, etc.

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

#93

Post by dep_b »

vlozko wrote: post #59
aquabeagle wrote: post #58

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.

I’m not against IB but the lack of stuff like constants is really difficult when a customer demands “same app, different skin”. SwiftUI seems to fix this.

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

#94

Post by gumby »

maxaf wrote: post #25
gumby wrote: post #16

Earlier quoted context omitted.

I consider this a feature: the older code has known behaviour, while a from-scratch implementation would have been a minefield of unknown bugs

I’m not buying your reasoning. Try putting a WKWebView into a SwiftUI view. This kind of thing is all sorts of messed up when multiple rendering systems - two of them declarative (SwiftUI and HTML) - collide in a single view. I’m sure someone’s going to call this a corner case, but useful and interesting apps that push the boundaries of the feasible are all composed of such “corner cases”. And hey, I’m not even doing…

I sympathize with your position and have had similar problems in the past. There’s no magic option. But typically the combination of a completely new API and implementation is very difficult for both implementors and users.

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

#95

Post by K0SM0S »

freehunter wrote: post #90
SquishyPanda23 wrote: post #89

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…

You're right, I didn't use the correct terminology and I appreciate the correction. On the other hand, using information from Facebook themselves (creators of React Native), the cross-platform solution seems to be able to scale pretty darn well [1]. Facebook, Instagram, Bloomberg, Skype, Walmart, Uber... these are some pretty big names with some pretty big audiences. If React Native can get your company from a startu…

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 when don't you run that remotely? On-premises offline pro apps maybe, like tools for e.g. plumbers and electricians? All of that stuff is in embedded afaik. Dedicated devices, rugged cases, it's a whole other market/target.

So cross-platform solutions on mobile indeed seem to fit most-if-not-all of the 'normal' use-cases, assuming there's server resource available. The Twitter/Rails example is one perfect illustration, and there are many such examples throughout big names we know today.

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

#96

Post by ronsor »

dfansteel wrote: post #52

Don’t underestimate the value of build tools. Just because you know Xcode and Swift or Android Studio and Kotlin (or their antecedent languages) are you done. Finally having a senior dev who knows what he’s talking about has done more for me in the past two years than the previous 8 of reading blog posts and hacking. He’s shown me the real value of build scripts. Today even my personal iOS projects are dependent on a…

>...dependent on a combination of Swift, Ruby, YAML, and Kotlin to build. It’s complicated to set up...

Can you elaborate on this? It just sounds like you have unnecessary complexity.

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

#97

Post by cschep »

aquabeagle wrote: post #58

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…

I've been doing iOS for a while and I also fought AutoLayout for too long. I found doing it in code better than trying to get IB right, especially when working on a team.

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

#98

Post by cschep »

wool_gather wrote: post #68
freehunter wrote: post #6

Earlier quoted context omitted.

Agreed. This absolutely kills me when people say “just read the documentation” or “the documentation is very good” as a reason why they don’t produce examples or templates or starter kits. Not all of us are CS majors or programmers in large teams or with decades of experience to fall back on. Just reading the documentation isn’t enough to get me into a new framework or language. I need to see practical examples. For…

Apple used to have a lot of pretty good (not perfect, but pretty good) conceptual/architectural documentation. Most of it has sadly been sunset, and is hard to find, even though it's still largely applicable. And it hasn't been replaced -- hopefully that's just "hasn't been replaced yet ".

This is so true and so sad. It was so good!

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

#99

Post by davnicwil »

freehunter wrote: post #73
mdocherty wrote: post #70

Earlier quoted context omitted.

I would be hesitant to recommend seriously pursuing cross-platform. Most serious applications generally run into scaling issues as they get more complicated and demands require more than the abstractions the cross-platform tool can provide.

On the other hand, very few applications need to scale to the point where it matters. If the options are "ship something now and refactor later" versus "ship something in six months that's perfect but too late", most people here would benefit from cross platform solutions. Very few companies have ever failed because their tech stack didn't scale well.

> Very few companies have ever failed because their tech stack didn't scale well

Just out of interest, are there any clear examples where this happened, ever? Can anyone name any?

What I mean specifically is - a company with a well known product that was growing in popularity but then hit a ceiling because of technical scale issues and couldn't support any more customers, growth halted, and they couldn't fix it in time to keep the momentum going (or got overtaken by a competitor) and failed?

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

#100

Post by ta32627888 »

rowathray wrote: post #78
blackrock wrote: post #60

Earlier quoted context omitted.

> I wish I knew mobile developers are some of the lowest paid developers other than game industry peons. Everything is relative of course, but can you back up your claim with some numbers? Where do you live? What salaries and compensation packages are you seeing?

https://stackoverflow.blog/2018/09/05/developer-salaries-in-... Well, ok, I guess it's not that grim. Still, it's a pretty crappy job.

> The specific technologies that developers use also impact salary. This year, the technologies most associated with high salary include Go, Scala, Redis, and React.

Surprised me seeing Scala in there, thought it was basically dead now. My last experience with seeing it in a codebase and using (or trying to use) SBT, I was kind of hoping it was.

Post reply on HN