Hey y'all.
I've been thinking recently about what a handmade approach looks like with mobile? At work, we used to use React Native (*shudders*) but are currently using Ionic (so hyrbrid). This was the right call in the short term because it's an internal app and we simply didn't have time to learn iOS and Android native development.
I've always been interested in mobile (specifically Android), but it is so rediculously tied-up in both OO and the custom JVM-ish layer they have. When I looked a bit into JNI with the NDK, it seemed like everyone said that it was very limited and very rough to work with.
On the other hand, it seems like Flutter itself is building their own stuff in C and OpenGL/maybe Metal? Is that what the answer would be? If so, how would one handle accessibility. Mobile seems like it's always a mess.
Anyway...does anyone here have relevant experience here?
-- James
I've been thinking recently about what a handmade approach looks like with mobile? At work, we used to use React Native (*shudders*) but are currently using Ionic (so hyrbrid). This was the right call in the short term because it's an internal app and we simply didn't have time to learn iOS and Android native development.
I've always been interested in mobile (specifically Android), but it is so rediculously tied-up in both OO and the custom JVM-ish layer they have. When I looked a bit into JNI with the NDK, it seemed like everyone said that it was very limited and very rough to work with.
On the other hand, it seems like Flutter itself is building their own stuff in C and OpenGL/maybe Metal? Is that what the answer would be? If so, how would one handle accessibility. Mobile seems like it's always a mess.
Anyway...does anyone here have relevant experience here?
-- James
Edited by James Sral
on
Reason: Initial post
If all you need is fullscreen windows with OpenGL/Vulkan context to render everything yourself then JNI is enough. Including getting inputs (touches, key presses, gamepad) and basic sensors - accelerometer and similar.
If using heavy IDE's doesn't scare you, then Android Studio integrates with NDK reasonably well. It does the build, packaging, deploying and debugging (not as good as MSVC, but obviously friendlier than gdb commandline). It can even step across Java/C boundaries, pretty neat.
Once you'll need extra things like native UI elements, then JNI will be not enough. Either you'll need to write those things in Java, or create tiny stubs that will forward everything to native code.
If using heavy IDE's doesn't scare you, then Android Studio integrates with NDK reasonably well. It does the build, packaging, deploying and debugging (not as good as MSVC, but obviously friendlier than gdb commandline). It can even step across Java/C boundaries, pretty neat.
Once you'll need extra things like native UI elements, then JNI will be not enough. Either you'll need to write those things in Java, or create tiny stubs that will forward everything to native code.
Interesting. It looks like for a standard app, then, Kotlin will be required. Perhaps I can minimize OO and external dependencies. Maybe the Handmade approach can apply in other areas. Like in web, my day job, using Vanilla JS until WebAssembly saved us all (fingers crossed).
Haven't really heard of web assembly, interested in how that is going to change how web dev is done?
Initially, web assembly was intended for just running computations in the browser that would be way too slow in JS. Recently, however, people have been working on running it as a standalone executable that is cross-platform and has security baked in. Hopefully it will mean that we can ship performant and sandboxes software instead of shoving everything into the browser. People now expect desktop quality apps in there browser, but it wasn't even remotely designed for that.
Interesting, is WASI what you're referring to? I hadn't heard about this standalone aspect.
If that takes off as a standard feature in modern browsers, it seems like the natural evolution of the web. Even though it started as a system for interlinked documents, the moment someone added a scripting API, we began torturing the web into a twisted application framework, and only tolerating its eccentricities because no other application framework provides what all web developers have really wanted since the early 2000s: the ability for users to load untrusted code over a network and run it in a sandbox without installing anything.
Maybe this will complete the 20-year, awkward transformation that began with JavaScript.
(Then again, I feel like a really complete transition would mean we just loaded actual machine code over the network and ran that in a sandbox. But maybe to be really viable that would require something like Casey Muratori advocates in "The Thirty-Million Line Problem," more standardized ISAs for complete machines.)
Getting back to the mobile issue, can WASI become an easier way to write cross-platform apps? The OS itself can even have a runtime built-in. Assuming you're making a fullscreen app with no standard UI stuff, maybe no need to use any Kotlin/Swift at all?
Disclaimer: I may be BSing a bit... I read a lot, but am mostly just a web developer by trade. |-(
If that takes off as a standard feature in modern browsers, it seems like the natural evolution of the web. Even though it started as a system for interlinked documents, the moment someone added a scripting API, we began torturing the web into a twisted application framework, and only tolerating its eccentricities because no other application framework provides what all web developers have really wanted since the early 2000s: the ability for users to load untrusted code over a network and run it in a sandbox without installing anything.
Maybe this will complete the 20-year, awkward transformation that began with JavaScript.
(Then again, I feel like a really complete transition would mean we just loaded actual machine code over the network and ran that in a sandbox. But maybe to be really viable that would require something like Casey Muratori advocates in "The Thirty-Million Line Problem," more standardized ISAs for complete machines.)
Getting back to the mobile issue, can WASI become an easier way to write cross-platform apps? The OS itself can even have a runtime built-in. Assuming you're making a fullscreen app with no standard UI stuff, maybe no need to use any Kotlin/Swift at all?
Disclaimer: I may be BSing a bit... I read a lot, but am mostly just a web developer by trade. |-(
Edited by winnythefoo
on
100% this! I hope WASI will help with mobile in the future. The trick is that we will still need some sort of standard APIs to interface with so that vendors can help build standards around accessibility. Ideally this will help development on all platforms. Mobile is just as much of a mess as web (if not more so since it takes forever to accomplish anything).
Mobile is the primary space that I work in professionally (mostly iOS), and I find it all comes down to each individual project. I've been fortunate in that most of the projects I've worked on, I have either built from the ground up, or I've had a big influence over how it was architected. If it's done right, mobile can be a nice space to work in. That being said, I've seen a lot of absolutely awful projects that are a complete mess, and it's true that the "best practices" or "accepted" development style on mobile is very much approaching that of the web (if not already there). I'm thinking React Native, Cocoapods, Carthage, Dagger, etc. etc. etc.
My handmade approach on mobile (I'll stick to iOS since that's my expertise, but I do a fair bit of Android development as well) is:
- no storyboards or visual layout (i.e. xib files); all layout is done in code
- no dependency managers (Cocoapods, etc.); if I have to use a library for something, I either just take the raw source files or get the framework/binary
- all native code (Swift)
- no external build system or distribution system (Fabric, etc.); just stick with Xcode and App Store Connect & Test Flight (this used to be much more of a pain years ago which made Fabric and other such services more appealing, but Apple has improved this process much more in the past couple of years)
As far as paradigms on mobile go, Android & Java leans heavily on OO, but on iOS & Swift it's much easier to break away from that. Swift is really more of a protocol-oriented language. However, both platforms and their SDKs definitely rely very much on the MVC pattern, so that's another strategy of mine -- put as much code as possible in the models as opposed to in the controllers (I've seen projects with gigantic view controllers which is just terrible design in my opinion).
My handmade approach on mobile (I'll stick to iOS since that's my expertise, but I do a fair bit of Android development as well) is:
- no storyboards or visual layout (i.e. xib files); all layout is done in code
- no dependency managers (Cocoapods, etc.); if I have to use a library for something, I either just take the raw source files or get the framework/binary
- all native code (Swift)
- no external build system or distribution system (Fabric, etc.); just stick with Xcode and App Store Connect & Test Flight (this used to be much more of a pain years ago which made Fabric and other such services more appealing, but Apple has improved this process much more in the past couple of years)
As far as paradigms on mobile go, Android & Java leans heavily on OO, but on iOS & Swift it's much easier to break away from that. Swift is really more of a protocol-oriented language. However, both platforms and their SDKs definitely rely very much on the MVC pattern, so that's another strategy of mine -- put as much code as possible in the models as opposed to in the controllers (I've seen projects with gigantic view controllers which is just terrible design in my opinion).
Fascinating. I guess I wasn't thinking as much about the iOS side since I have a more personal connection to Android. The fake-JVM is a bummer on that side. I do have plenty of respect for Swift though. Your approach makes total sense to me!
Frankly, I'm also not really qualified to be railing against mobile as my only experience is with React Native and Ionic (since I do primarily web dev (which is also a mess, haha)).
Frankly, I'm also not really qualified to be railing against mobile as my only experience is with React Native and Ionic (since I do primarily web dev (which is also a mess, haha)).
I work in the mobile space for a living, and I would say the biggest challenge is less technical and more educational. Most people coming into mobile aren't aware of its rich backstory and underpinnings in native programming languages like C.
People are only familiar with the frameworks and SDKs the major platform providers give them. They don't know that those frameworks and SDKs are built on top of lower level languages, and the documentation for the lower level tools isn't all that transparent. Many mobile developers wouldn't even know where to begin if they wanted to try building a totally cross-platform mobile app in C, for example.
And that's even assuming a person comes into this with the genuine intent to learn and understand what's actually going on. Plenty of mobile developers are totally content consuming some web-based framework like React Native, which somehow exists at a level above what I would consider "high level," (frameworks like UIKit / Foundation, basically anything in Objective-C or Swift that Apple officially suggests we use to build iOS apps). A similar thing would apply to Android development as well.
In addition, we have a build system that is pretty damn opaque. A person coming into mobile app development is in some sense hopping onto a moving train. You download Xcode, you're given the tools to build your project, you literally press a "play" button to build and run on your device, and you don't need to know anything about how any of that works. It takes a substantial time investment to break all of that down to the shell script commands that are actually used. It's totally doable, but not for the sort of person who casually stumbles upon it, and rolling a custom build system certainly wouldn't fly in most "fast-paced" mobile development teams. You would get fired on your first week if people got word of you doing that.
I would suspect that if any of us could break past that initial barrier, we might find ourselves trying to do some sort of minimal "platform layer," although I doubt it would look anything like the platform layer in Handmade Hero. With games, you're lucky you can just pass a few pointers to some buffers over to the game library. Generally, there's much less platform-specific code.
It's different in mobile. There is an expectation that you will deliver the app faster, which means taking advantage of existing SDKs (on all platforms). In that scenario, a cross-platform app library looks more like the shared logic / entities present in the app on all platforms. The app still calls into the native SDKs, but it is using logic in the cross-platform library to figure out what to put on the screen.
That could mean a lot of things depending on the sort of app you're trying to build, but it might mean common screen layouts that exist on all platforms, common text validation logic, data types, etc. You would use the native SDKs to get the native looks and feel while drawing from a single C library representing commonalities between all platforms.
I haven't actually tried any of this in my job yet. I suspect I would have a difficult time selling this idea to most developers, since many of them lack the technical foundation to see how all of the pieces interact with another. And that's another problem with this approach.
You might understand how to do it, but I can practically guarantee that most mobile teams I've worked on have people siloed into very specific roles. You've got the iOS person and the Android person. I have never run into a developer who knows C and how it interfaces with Objective-C and Java. If you try to build a team around that skillset you may never get the people you want.
Sadly, lots of technical decisions aren't made because they're the right thing to do from an engineering standpoint. They're made because of the hiring landscape. I think that's a big reason why we're witnessing the popularity of things like React Native. There are more web developers than native, and it's much easier to hire for those sorts of roles. In a better world, people would be more motivated to gain deeper knowledge of the platforms they're working on, but we don't live in that world and many companies are forced to deal with that reality. They hire who they can, and they form teams around the skills they have, not the skills they wish they could get.
Again, I'm not trying to say this is "good" or desirable. I think it sucks, especially if you're the sort of person who doesn't like handwaving and magical thinking when you do your work. I have to say it has been especially difficult for me, as I am generally not a dogmatic thinker. The mobile app world is full of people espousing the cool thing of the day, whether that's OOP, functional programming, or some kind of Model-View-View-Model-Monadology thingy. It's all horse shit, and indicative of peoples' inability to think for themselves.
Trying to make a difference over here. It's a long long road though.
People are only familiar with the frameworks and SDKs the major platform providers give them. They don't know that those frameworks and SDKs are built on top of lower level languages, and the documentation for the lower level tools isn't all that transparent. Many mobile developers wouldn't even know where to begin if they wanted to try building a totally cross-platform mobile app in C, for example.
And that's even assuming a person comes into this with the genuine intent to learn and understand what's actually going on. Plenty of mobile developers are totally content consuming some web-based framework like React Native, which somehow exists at a level above what I would consider "high level," (frameworks like UIKit / Foundation, basically anything in Objective-C or Swift that Apple officially suggests we use to build iOS apps). A similar thing would apply to Android development as well.
In addition, we have a build system that is pretty damn opaque. A person coming into mobile app development is in some sense hopping onto a moving train. You download Xcode, you're given the tools to build your project, you literally press a "play" button to build and run on your device, and you don't need to know anything about how any of that works. It takes a substantial time investment to break all of that down to the shell script commands that are actually used. It's totally doable, but not for the sort of person who casually stumbles upon it, and rolling a custom build system certainly wouldn't fly in most "fast-paced" mobile development teams. You would get fired on your first week if people got word of you doing that.
I would suspect that if any of us could break past that initial barrier, we might find ourselves trying to do some sort of minimal "platform layer," although I doubt it would look anything like the platform layer in Handmade Hero. With games, you're lucky you can just pass a few pointers to some buffers over to the game library. Generally, there's much less platform-specific code.
It's different in mobile. There is an expectation that you will deliver the app faster, which means taking advantage of existing SDKs (on all platforms). In that scenario, a cross-platform app library looks more like the shared logic / entities present in the app on all platforms. The app still calls into the native SDKs, but it is using logic in the cross-platform library to figure out what to put on the screen.
That could mean a lot of things depending on the sort of app you're trying to build, but it might mean common screen layouts that exist on all platforms, common text validation logic, data types, etc. You would use the native SDKs to get the native looks and feel while drawing from a single C library representing commonalities between all platforms.
I haven't actually tried any of this in my job yet. I suspect I would have a difficult time selling this idea to most developers, since many of them lack the technical foundation to see how all of the pieces interact with another. And that's another problem with this approach.
You might understand how to do it, but I can practically guarantee that most mobile teams I've worked on have people siloed into very specific roles. You've got the iOS person and the Android person. I have never run into a developer who knows C and how it interfaces with Objective-C and Java. If you try to build a team around that skillset you may never get the people you want.
Sadly, lots of technical decisions aren't made because they're the right thing to do from an engineering standpoint. They're made because of the hiring landscape. I think that's a big reason why we're witnessing the popularity of things like React Native. There are more web developers than native, and it's much easier to hire for those sorts of roles. In a better world, people would be more motivated to gain deeper knowledge of the platforms they're working on, but we don't live in that world and many companies are forced to deal with that reality. They hire who they can, and they form teams around the skills they have, not the skills they wish they could get.
Again, I'm not trying to say this is "good" or desirable. I think it sucks, especially if you're the sort of person who doesn't like handwaving and magical thinking when you do your work. I have to say it has been especially difficult for me, as I am generally not a dogmatic thinker. The mobile app world is full of people espousing the cool thing of the day, whether that's OOP, functional programming, or some kind of Model-View-View-Model-Monadology thingy. It's all horse shit, and indicative of peoples' inability to think for themselves.
Trying to make a difference over here. It's a long long road though.
Edited by Ted Bendixson
on
tedbendixson
I work in the mobile space for a living, and I would say the biggest challenge is less technical and more educational. Most people coming into mobile aren't aware of its rich backstory and underpinnings in native programming languages like C.
Yes, I think education, but also implied in your post is attitude. Particularly around "app development" (mobile, web, desktop), many developers don't seem at all interested in really understanding how things work. The pervasiveness around the use of frameworks & libraries to solve simple problems is baffling to me. "But that's how it's done," it usually goes. And then we run into all sorts of issues with said frameworks/libraries/SDKs and shrug it off like "well, that's software development." It's upsetting to me why more developers don't see the benefit of vastly reducing & limiting external dependencies.
tedbendixson
Plenty of mobile developers are totally content consuming some web-based framework like React Native, which somehow exists at a level above what I would consider "high level," (frameworks like UIKit / Foundation, basically anything in Objective-C or Swift that Apple officially suggests we use to build iOS apps). A similar thing would apply to Android development as well.
I wish there was more foresight by developers and PMs on the dangers of using React Native and other such frameworks. Sure, we would all love to work in a common codebase for all our platforms, but that ideal never works in our current ecosystem and frameworks like React Native don't solve it. A couple of years ago or so, I read that AirBnB completely abandoned their React Native apps and rebuilt them for iOS and Android natively. RN just doesn't pay off in the long run.
tedbendixson
You might understand how to do it, but I can practically guarantee that most mobile teams I've worked on have people siloed into very specific roles. You've got the iOS person and the Android person. I have never run into a developer who knows C and how it interfaces with Objective-C and Java. If you try to build a team around that skillset you may never get the people you want.
I worked on an iOS & Android project that used a custom-built renderer written in C (it was a home renovation visualizer app) that I maintained for awhile. When I moved on to other things, I was called on to consult on this project for a full year because they couldn't find anyone with that overlap of skillset.
tedbendixson
The mobile app world is full of people espousing the cool thing of the day, whether that's OOP, functional programming, or some kind of Model-View-View-Model-Monadology thingy. It's all horse shit, and indicative of peoples' inability to think for themselves.
This is one of the things I find most grating.. adopting technologies/services "just because". What problem does it solve? Does it solve it better/faster than you can? Critically evaluating dependencies you bring into your codebase should be far more important than it is!
This may be slightly off topic, but some new players are entering the market. Most importantly, Purism with the Librem 5 phone. They've really made huge strides in making open hardware and one of their key pillars is to allow native development. Now, of course they won't overtake Android or iOS overnight, but they're further along than anyone else to make important changes in the mobile space happen.
I would highly recommend anyone interested in mobile development to look up the Librem 5. Again, it's still very much in its infancy, but I do believe that they can succeed in the long term and bring open hardware, free software and native applications (back) into the mobile space.
EDIT: timestamped video of the CEO of Purism talking specifically about native applications:
https://youtu.be/YDOHk8GB00M?t=527
I would highly recommend anyone interested in mobile development to look up the Librem 5. Again, it's still very much in its infancy, but I do believe that they can succeed in the long term and bring open hardware, free software and native applications (back) into the mobile space.
EDIT: timestamped video of the CEO of Purism talking specifically about native applications:
https://youtu.be/YDOHk8GB00M?t=527
Edited by mcalis
on
Flyingsand
- no external build system or distribution system (Fabric, etc.); just stick with Xcode and App Store Connect & Test Flight (this used to be much more of a pain years ago which made Fabric and other such services more appealing, but Apple has improved this process much more in the past couple of years)
Hell yes to this one! I find it utterly ridiculous how many projects start out with some complicated external build system from day one. We're just trying to prototype a thing. We don't need automated builds until there is a business need to deliver builds more frequently. Why waste all of this time setting something up and maintaining it if you're just going to put out a build every few weeks to a month?
Developers. I swear. They just *want* to churn.
FlyingSand
I worked on an iOS & Android project that used a custom-built renderer written in C (it was a home renovation visualizer app) that I maintained for awhile. When I moved on to other things, I was called on to consult on this project for a full year because they couldn't find anyone with that overlap of skillset.
I'm pretty well convinced that is how you stay employed on your own terms. You become the sort of person who they know can go low-level and wrestle with some thorny problem nobody else can. Truly, the kind of learning and mindset you get from Handmade Hero and the sorts of people who hang out in these forums will make you eminently employable. I noticed an uptick in my ability to keep contracts and get work once I started following the series more closely and building more things from scratch (lol I also noticed an uptick in my disgust with the typical way software development is done but that's a different story).
All good points. It's frustrating, but I think there is hope. For instance, in webdev we have Go which is bringing people to do things much more simply and with fewer dependencies. Even on the frontend, the "Vanilla JS" movement seems to be gaining traction. I just saw this book on "Modest JS" pop up yesterday and it's great! I think there are those of us who are beginning to wake up to this stuff, so hopefully mobile will come around eventually as well.