Show HN: Rumblelist, a React-based task app. Trying to build mobile version(rumblelist.com)
rumblelist.com
Show HN: Rumblelist, a React-based task app. Trying to build mobile version
https://www.rumblelist.com/why-another-task-manager/
19 comments
If you guys are trying react native, you could try mobile.azure.com for the devops pipeline.
The scroll to top button appears to cover the live chat button on mobile.
This is a new app I am trying to launch. We had a ton of success with React as the web app, but building the mobile stuff has really slowed us down.
You might want to consider using Cordova. The performance is pretty good these days, and you could probably reuse most of your existing codebase.
Can you say more about the obstacles you've encountered building the mobile app? Just curious.
So, first off, I've never done mobile, but I've been writing software for 30 years. The biggest issues are probably obvious and are heard all over the place:
1) cross platform mobile-app development is a nightmare. I tried Xamarin and gave up because I felt like I would have to learn an whole new layer of syntax to do any UX work. Also the build times, the heavy lifting that was going to be required to setup the simulation environments, etc. just didn't make sense.
2) Setting up your development environment is just a complete nightmare. After a week or two of messing around, I finally got the Android emulators working at reasonable performance on my Windows machine. Still haven't even attempted to hook up a mac.
3) The amount of third party code, npm modules, and pre-processing required to build the simplest shell application is astounding. My current "shell" app, after first build, is 32k files and almost 300MB. Its absurd. and the app doesn't even do ANYTHING yet. The problem with all this code is that no one can possibly understand ALL this plumbing, and the instant something goes wrong, you're immediately sucked into non-productive rabbit holes.
All that being said, this is an awesome learning experience. I've been avoiding mobile development for years hoping it would mature, and I guess it has somewhat, but at this point, feeling like I won the lottery when I finally was able to set a breakpoint in my VS Code editor, run a react-native application through the emulator and hit the breakpoint. Ha!
1) cross platform mobile-app development is a nightmare. I tried Xamarin and gave up because I felt like I would have to learn an whole new layer of syntax to do any UX work. Also the build times, the heavy lifting that was going to be required to setup the simulation environments, etc. just didn't make sense.
2) Setting up your development environment is just a complete nightmare. After a week or two of messing around, I finally got the Android emulators working at reasonable performance on my Windows machine. Still haven't even attempted to hook up a mac.
3) The amount of third party code, npm modules, and pre-processing required to build the simplest shell application is astounding. My current "shell" app, after first build, is 32k files and almost 300MB. Its absurd. and the app doesn't even do ANYTHING yet. The problem with all this code is that no one can possibly understand ALL this plumbing, and the instant something goes wrong, you're immediately sucked into non-productive rabbit holes.
All that being said, this is an awesome learning experience. I've been avoiding mobile development for years hoping it would mature, and I guess it has somewhat, but at this point, feeling like I won the lottery when I finally was able to set a breakpoint in my VS Code editor, run a react-native application through the emulator and hit the breakpoint. Ha!
It's something all software developer i know always underestimate when they think about mobile development. The ecosystem and tools are so abysmally bad compared to desktop or server development or even web now, that most of them don't understand the high development cost or the difficulty of doing high quality code.
Even Apple, which control everything from cpu design to compiler to programming language to IDE don't manage to have anything decent. xcode should be rewritten from scratch, swift compiler crash every two lines, iOS is becoming cumbersome and starts to show its age, new tech like autolayout is slow as hell or simply doesn't work (core data on icloud), compiling takes ages, xib and xcodeproj file format crash and burn as soon as you start to collaborate with git, deploying to the appstore still feels like rolling a dice (whenever the uploading itself doesn't bug), and in addition to all this mess, you give them 30% of your income. And when you think it's over, you realize they butcher your income report ( in pretty pretty csv file format) if you don't download them after two months.
The only thing that saves them is that android has managed to have an even worse experience.
Honestly, there's so much room today for a new mobile ecosystem, i wouldn't be surprised if either microsoft, or a newcomer from china starts to make a revolution in some way pretty soon. If microsoft were to resurrect windows mobiel together with a good phone, as well as a good C# + visual studio programming environment, i may sincerely give it a try, at least for my b2b applications.
Even Apple, which control everything from cpu design to compiler to programming language to IDE don't manage to have anything decent. xcode should be rewritten from scratch, swift compiler crash every two lines, iOS is becoming cumbersome and starts to show its age, new tech like autolayout is slow as hell or simply doesn't work (core data on icloud), compiling takes ages, xib and xcodeproj file format crash and burn as soon as you start to collaborate with git, deploying to the appstore still feels like rolling a dice (whenever the uploading itself doesn't bug), and in addition to all this mess, you give them 30% of your income. And when you think it's over, you realize they butcher your income report ( in pretty pretty csv file format) if you don't download them after two months.
The only thing that saves them is that android has managed to have an even worse experience.
Honestly, there's so much room today for a new mobile ecosystem, i wouldn't be surprised if either microsoft, or a newcomer from china starts to make a revolution in some way pretty soon. If microsoft were to resurrect windows mobiel together with a good phone, as well as a good C# + visual studio programming environment, i may sincerely give it a try, at least for my b2b applications.
I completely agree on every point. Developers are such a creative bunch, I'm just surprised this has gone on so long. I went into this wary but hopeful that mobile dev had gotten to a good point, but I am just not seeing it.
I'd love to be able to just hook my editor up to a cloud environment that took care of all this for me :-)
I'd love to be able to just hook my editor up to a cloud environment that took care of all this for me :-)
I've been writing software for over 30 years as well, just recently came to mobile (Android) after coding just about every other platform on earth.
I have an Android app published now, but it was a complete nightmare as you say and I'm more convinced than ever that most things should be done as web apps, perhaps progressive web apps rather than native if you want to write cross platform.
I have an Android app published now, but it was a complete nightmare as you say and I'm more convinced than ever that most things should be done as web apps, perhaps progressive web apps rather than native if you want to write cross platform.
PM building the VSCode react native extension here. Glad that you could get breakpoints working. There are also other features like syntax completion and simply trying out react native without and installation using exponent that nasty be interesting.
Would love to hear any other feedback you may have on the authoring experience.
Would love to hear any other feedback you may have on the authoring experience.
Ah, yes, the tools involved with mobile development can be frustrating. FWIW, I generally skip the emulator/simulator and go straight to testing on the device. For iOS, you have to mess with Apple developer program membership, code signing, and provisioning profiles to run an app on the device. But for Android, just enable debugging on your device, connect via USB, and use adb.
About learning a "new syntax" for Xamarin, do you just mean that you don't know C#? Or are you talking about XAML? As I understand it, XAML is basically .NET's JSX, but with a sharper division between the declarative markup and the code (or "code behind" as it's called in the .NET world). Charles Petzold's book about Xamarin Forms does a good job of demystifying XAML.
I have mixed feelings about Xamarin versus React Native. On the one hand, React Native is fairly easy to integrate into an existing mobile app, and it integrates with each platform's native development tools (Xcode for iOS, Gradle for Android). That's not the case for Xamarin; in particular, on iOS, Xamarin uses its own AOT native code compiler based on LLVM. The next time that Apple puts out a new version of Xcode and, the same day, introduces a new requirement for app store submissions (for a new platform if not for iOS itself), Xamarin users are stuck until Xamarin scrambles to update its compiler.
On the other hand, with Xamarin, the resulting app is more native in ways that users can actually perceive, even when using Xamarin Forms. To take a simple example, React Native's (new) Button component doesn't actually use a UIButton on iOS or the equivalent on Android. So what happens when a future version of the platform changes the appearance of a button's border? Now React Native's hard-coded styles are out of date. A more complex example that's actually more relevant to me is React Native's ListView component. It doesn't use UITableView on iOS or the native ListView on Android. I don't know what this means for Android, but for iOS, the difference is noticeable, at least to blind people using an app with VoiceOver. Bring up the UIExplorer app on a device, turn on VoiceOver, and swipe through the screen. Notice that VoiceOver doesn't automatically scroll through the list; you have to do that manually with a three-finger swipe up. Contrast that with any native UITableView. My feeling is that React Native's developers will use native components in situations where they know they can't duplicate the native behavior, but if they think they can produce a cross-platform JS component that feels native enough, they will. Given the great momentum of React Native, which isn't likely to stop any time soon, I guess I should stop ranting and actually fix the problem, or at least the user-visible symptoms.
I haven't used either Xamarin or React Native for a real project yet. For my latest mobile project, I tried to take the Google Inbox approach, that is, writing non-UI code in cross-platform Java, then writing each platform's UI in that platform's native language. Then for iOS, I use Google's J2ObjC to compile the cross-platform Java into ObjC. But I'm not really happy with this approach. My guess is that all the best practices for writing an app this way are only known by the teams within Google that are doing it. There certainly isn't a strong community of developers outside of Google using this approach. And while cross-platform UI toolkits are criticized for being prone to the uncanny valley problem, my experience writing a desktop app with SWT suggests that you can go a long way with a cross-platform UI toolkit, as long as the toolkit is based on the highest-level native facilities that are applicable, and you can drop down to native when necessary. So I'm looking at cross-platform mobile development solutions that actually have strong developer communities behind them, and Xamarin and React Native are the top contenders.
This long-winded rant is the product of my last few weeks of thinking about cross-platform mobile development and surveying the landscape. Perhaps this thread wasn't the best place for it to finally burst out. Just know that it's a vexing problem even for someone who's been doing mobile development intermittently for a while (6 years for an iOS app, 3 years for the Android version).
Good luck with your mobile app.
About learning a "new syntax" for Xamarin, do you just mean that you don't know C#? Or are you talking about XAML? As I understand it, XAML is basically .NET's JSX, but with a sharper division between the declarative markup and the code (or "code behind" as it's called in the .NET world). Charles Petzold's book about Xamarin Forms does a good job of demystifying XAML.
I have mixed feelings about Xamarin versus React Native. On the one hand, React Native is fairly easy to integrate into an existing mobile app, and it integrates with each platform's native development tools (Xcode for iOS, Gradle for Android). That's not the case for Xamarin; in particular, on iOS, Xamarin uses its own AOT native code compiler based on LLVM. The next time that Apple puts out a new version of Xcode and, the same day, introduces a new requirement for app store submissions (for a new platform if not for iOS itself), Xamarin users are stuck until Xamarin scrambles to update its compiler.
On the other hand, with Xamarin, the resulting app is more native in ways that users can actually perceive, even when using Xamarin Forms. To take a simple example, React Native's (new) Button component doesn't actually use a UIButton on iOS or the equivalent on Android. So what happens when a future version of the platform changes the appearance of a button's border? Now React Native's hard-coded styles are out of date. A more complex example that's actually more relevant to me is React Native's ListView component. It doesn't use UITableView on iOS or the native ListView on Android. I don't know what this means for Android, but for iOS, the difference is noticeable, at least to blind people using an app with VoiceOver. Bring up the UIExplorer app on a device, turn on VoiceOver, and swipe through the screen. Notice that VoiceOver doesn't automatically scroll through the list; you have to do that manually with a three-finger swipe up. Contrast that with any native UITableView. My feeling is that React Native's developers will use native components in situations where they know they can't duplicate the native behavior, but if they think they can produce a cross-platform JS component that feels native enough, they will. Given the great momentum of React Native, which isn't likely to stop any time soon, I guess I should stop ranting and actually fix the problem, or at least the user-visible symptoms.
I haven't used either Xamarin or React Native for a real project yet. For my latest mobile project, I tried to take the Google Inbox approach, that is, writing non-UI code in cross-platform Java, then writing each platform's UI in that platform's native language. Then for iOS, I use Google's J2ObjC to compile the cross-platform Java into ObjC. But I'm not really happy with this approach. My guess is that all the best practices for writing an app this way are only known by the teams within Google that are doing it. There certainly isn't a strong community of developers outside of Google using this approach. And while cross-platform UI toolkits are criticized for being prone to the uncanny valley problem, my experience writing a desktop app with SWT suggests that you can go a long way with a cross-platform UI toolkit, as long as the toolkit is based on the highest-level native facilities that are applicable, and you can drop down to native when necessary. So I'm looking at cross-platform mobile development solutions that actually have strong developer communities behind them, and Xamarin and React Native are the top contenders.
This long-winded rant is the product of my last few weeks of thinking about cross-platform mobile development and surveying the landscape. Perhaps this thread wasn't the best place for it to finally burst out. Just know that it's a vexing problem even for someone who's been doing mobile development intermittently for a while (6 years for an iOS app, 3 years for the Android version).
Good luck with your mobile app.
yea, cut me I bleed C# .. the transition to client libraries has been hard enough, but mobile has thrown me in a tizzy.
The straight up performance of Xamarin on my development machine was what through me. Getting it all setup and rolling and seeing the incredible amount of heavy lifting it took to get something rolling just turned me off completely.
I see what you mean about react-native, but from my perspective, the next-best-thing is a far enough second place finisher that I don't want to consider it. I still feel a native web based app running on all platforms is the ultimate best way to roll. We just need Apple to stop fighting it.
The straight up performance of Xamarin on my development machine was what through me. Getting it all setup and rolling and seeing the incredible amount of heavy lifting it took to get something rolling just turned me off completely.
I see what you mean about react-native, but from my perspective, the next-best-thing is a far enough second place finisher that I don't want to consider it. I still feel a native web based app running on all platforms is the ultimate best way to roll. We just need Apple to stop fighting it.
Nativescript has been a godsend to me of turning working web apps into mobile apps.
I've been trying to stay away from Angular development. I've heard that ecosystem is just in a tizzy right now.
Maybe consider a progressive web application (PWA). A couple interesting articles I've read recently:
https://medium.com/javascript-scene/native-apps-are-doomed-a...
https://medium.com/javascript-scene/why-native-apps-really-a...
https://medium.com/javascript-scene/native-apps-are-doomed-a...
https://medium.com/javascript-scene/why-native-apps-really-a...
Started reading those articles and immediately loved it. I did a bit of research a few weeks back because I had already been considering this approach. The consensus seemed to be that the app would suffer from performance issues primarily.
Ok, so I read through those articles and my curiosity is peaked. If you had to guess, what would be your ETA on support for PWA's on IOS.. I think thats the elephant in the room.
I'm somewhat curious if native mobile apps might start falling out of favor...at least for apps that mostly pull outside data.
I see the advantage for things that run fully (or mostly) locally, like games.
I don't really understand the advantage for other types of applications. Airline apps are a good example. Everything that's interesting about them requires live data that isn't stale. Yet these types of apps are very popular. I assume browsers will start closing on whatever functional gaps make it this way. The wasted time/effort to create 4 distinct experiences (desktop, mobile web, IOS, Android) irks me.
I see the advantage for things that run fully (or mostly) locally, like games.
I don't really understand the advantage for other types of applications. Airline apps are a good example. Everything that's interesting about them requires live data that isn't stale. Yet these types of apps are very popular. I assume browsers will start closing on whatever functional gaps make it this way. The wasted time/effort to create 4 distinct experiences (desktop, mobile web, IOS, Android) irks me.
To me, personally, its the trade off. A well built responsive HTML based UX is the easiest development approach. The thing that concerns me is that I don't know how much "easier" mobile dev can get, and I don't think it can come anywhere close to raw web based dev. So I concur :-)