> the apps I write are really small, really secure, really fast, accessible, highly usable, use very few system resources, leverage the latest Apple tech, have almost no external dependencies, work extremely well, and I write them very, very quickly.
And they're only available for one proprietary platform [1], no? Excluding half of the user base for phones (in the US), and probably much more for personal computers, seems like a really bad business move in many cases. And depending on the type of application, it could be considered a different type of accessibility problem. It's depressing, but so often we have to compromise technical excellence and even user experience for economic reasons; in this case, using a cross-platform technology to develop a suckier app that can reach all host platforms is often the smart business move.
See, here's the deal: I really don't care. I love writing the apps I write, using the tools I use, for the target devices that I target.
I do this for the love of the Craft.
But I completely get you, about the business reasons. I can't, in good conscience, argue against most deployments of hybrid systems.
What is sad, is companies that release shoddy hybrid apps, developed by lowest-bid offshore shops (who often do a better job than onshore ones), then refuse to continue supporting their crapplets.
> What is sad, is companies that release shoddy hybrid apps, developed by lowest-bid offshore shops (who often do a better job than onshore ones), then refuse to continue supporting their crapplets.
The other thing that bums me out about cross platform “solutions” as a fellow UIKit/AppKit dev is their lowest-common-denominator design, making them incapable of the features that make each OS unique and interesting. I’d like to see the opposite approach, where if platform A was missing something that platform B had, the framework would instead fill the gaps and provide that capability on platform A too. At least for me that’d make cross platform development a good deal more pleasant.
As you noted, a robust set of widgets and capabilities out of the box is important too. The miles-long dependency list that comes with the typical JS app stack is unappealing at best, and nothing is worse than having to hunt down an implementation of a widget you need only to find that the 4 options available all have huge holes in functionality in different places, with 2 in some state of disrepair and 1 not being suitable for your project for some miscellaneous reason.
I doubt that this would pose an issue for most bits of desktop software UI. Most UI patents tend to be focused on specific parts of apps (e.g. the Instagram profile page layout), rather than on more broad UI features like toolbars. They also tend to be more focused on mobile UI, desktop UI hasn’t really moved much in the past 20 years aside from cosmetic tweaks.
And, if I cleave to the Apple toolset (as opposed to rewriting it, like I used to), that stuff is sorted. Apple has much better lawyers than I'll ever be able to afford.
Also, I use lots of dependencies. It's just that they are generally ones that I wrote.
What is sad, is companies that release shoddy hybrid apps, developed by lowest-bid offshore shops (who often do a better job than onshore ones), then refuse to continue supporting their crapplets.
Actually, that's not the sad part. The sad part is that Apple, despite being one of the richest companies in the world, basically doesn't care about any attempt to make this situation better, and actually actively works against it.
I work on a cross platform desktop application win/mac, and the process of dealing with OSX development is so frustrating it essentially does not make sense for the size of the user-base. You need Apple hardware to develop. You need an Apple developer account to develop. Xcode is incredibly unstable. C++ support of Clang is out of date. IT management of a fleet of OSX devices is a pain. Notarization and code signing fails regularly due to Apple server downtime. Documentation is horrible, many issues you face must be solved through forum posts where other people shotgun debugged their way out and shared the results. OSX systems are not dependable as long running build servers, frequently causing issues with keychain locks, expiring credentials, volume dismounts, blocking remote access, etc.
On top of that Apple happily blocks any attempt you make at doing cross platform work properly by avoiding support for cross platform APIs: OpenGL is stuck 10 years in the past, and now officially deprecated. Vulkan is not supported. Only supported graphics API is Metal, which is proprietary. WebGL2 support took 5 years to arrive in safari after chrome/ff. WebGPU is likely to follow the same pattern. IOS is locked to a single browser engine. Any attempt to make a webpage behave like an app, works on android but not ios. (example: https://caniuse.com/gyroscope).
Apple doesn't want hybrid apps to work at all, and is busy strangling any initiatives for cross platform APIs. If the browser were invented today Apple would be the first to proclaim a proprietary alternative that would be incompatible and split the world in half. It has created an ecosystem isolated from the world, just the way it likes. As a developer you can learn their ecosystem, and place yourself inside it. However, don't fool yourself into thinking that you are allowing Apple users to use your application, no sir, instead Apple is kind enough to allow you to develop your app for Apple users, and that kindness may expire at any time.
I really cannot understand why a developer would choose to live in such an uncontrollable, closed down, anti-developer system, and even evangelize it.
Apple hates you, why do you love it back? Is this stockholm syndrome?
That wasn’t a bad rant, until the last two sentences.
I do what I do, get the results that I get, and I don’t need to justify it to those that view me with contempt.
A number of years ago, I did take a few months, and learned native Android development (Java, at the time). It was a serious effort, and I spent months, learning the IDE, build system, Play Store, etc. I did publish an app on the Play Store (long since deceased, but I still get Google spam, from it).
I found it to be unpleasant, and returned to the Apple fold. This was nothing against the system. I just didn’t like it.
Aha, I did not intend to be contemptuous to you personally, sorry about that. And you do not need to justify anything to me, my rant is more of the untargeted frustration kind. I understand the desire to work in a straightforward manner that suits you personally, I am just sad the same thing cannot be achieved across all the platforms.
I’m with you. I’m also an iOS (as well as macOS) developer. I started doing Cocoa development a few years before the iPhone came out, when it was much more of a niche than it is now. I’ve never had trouble making a very good living doing it, but I really started and continue to enjoy it because it enables me to create the things I want to create, right through to a polished UI that fits in with my favorite platforms to use.
You could make another app for Android. I think it's an unsettled question that one cross-platform app is a better business move than two independent apps.
There are use cases, where a hybrid system is the most useful path. These are usually cases, where the main product is a server-based service, and the apps are really fairly basic "skins" of the service.
But usability is always reduced, in cross-platform systems. I have been writing cross-platform stuff for decades. Usually, I wrote the Apple part, and another developer wrote the [usually] Windows part. We have tried things like Qt, which is acceptable, but not especially nice.
No matter how much people crow about how hybrid systems are "every bit as good" as native systems; they are wrong.
If you (and/or your users) care a lot about the Quality of the user experience, then native is the way to go. This is especially true, if there are unusual user interface concepts and widgets involved.
No matter how you write it, though, a released software product is a Responsibility. I liken it to having children. Making them is fun. Having them, is less fun. Once they are in your life, you are Responsible for them.
I’m not sure vscode (or JS for that matter) is necessarily slow anymore. I find the potential for speed in the JavaScript world often comes down to good design decisions. vscode performance issues have often been resolved with better design. These days it’s impressively snappy. Of course there are limitations and JS isn’t a top shelf performance language, but for most things with a UI it is pretty good now.
Electron seems to eat a lot of resources, but it can still be fast. I think it tends not to be because the people building stuff with it aren’t necessarily well-versed in writing software. Or perhaps they don’t have the time and resources to make it happen due to constantly shifting business goals, for example.
By all means vscode rarely presents performance issues for me anymore, even on my 2017 MacBook Air. Some things can be slow, but they tend to be specific to extensions and not vscode itself.
This is my experience with using React Native. I commented on it recently in another context, which was that my team of relatively competent people had a surprisingly hard time keeping the build and deployment pipeline happy. It was a lot of overhead. We essentially had to live with knowing we had low confidence in it, and there wasn’t much to do about it.
Anyway, the actual end result was impressive for how much code we were able to reuse, we were able to build it pretty quickly, etc.
But it wasn’t that great in a number of more subtle ways, like in terms of usability as you mention. Accessibility features were missing in some cases. Various behaviours didn’t match the OS quite right, and we couldn’t easily find ways to make it happen. Text handling of all things was extremely convoluted and hard to get right.
You’re right that it suits cases where you want a skin over a more complex back end service. But even then, I’m not convinced it isn’t worth learning to build with native tools.
We’re obsessed with saving time. Every team I’ve worked on that tried to save time was just saving time to build more stuff with corners being cut. It’s rarely actually worth it. Make a few things, do it well, and I bet you’ll see better results than if you build 100 shitty things.
I’m not particularly successful in software so who knows, I’m certainly not an authority.
And they're only available for one proprietary platform [1], no? Excluding half of the user base for phones (in the US), and probably much more for personal computers, seems like a really bad business move in many cases. And depending on the type of application, it could be considered a different type of accessibility problem. It's depressing, but so often we have to compromise technical excellence and even user experience for economic reasons; in this case, using a cross-platform technology to develop a suckier app that can reach all host platforms is often the smart business move.
[1]: Well, one platform for each form factor.
reply