5 ms·

> 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

> 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. [1]: Well, one platform for each form factor.

ChrisMarshallNY 5y ago
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.
- kitsunesoba 5y ago
  > 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.
  - mwcampbell 5y ago
    > the framework would instead fill the gaps Might this be asking for patent trouble, though?
    - kitsunesoba 5y ago
      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.
      - ChrisMarshallNY 5y ago
        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. I have control issues, I guess... Everyone wants to write unique UI, but I've learned that's a trap. I write about that, here: https://littlegreenviper.com/miscellany/the-road-most-traveled-by/ https://littlegreenviper.com/miscellany/the-road-most-travel...
- vouwfietsman 5y ago
  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 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?
  - ChrisMarshallNY 5y ago
- armadsen 5y ago
  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.
travisjungroth 5y ago
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.
- ChrisMarshallNY 5y ago
  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.
  - krzat 5y ago
    > But usability is always reduced, in cross-platform systems. A native app is limited by capabilities of the platform. Perhaps Xcode is so bad because AppKit does not quite support the use case. On the other hand you have VSCode, a slow Electron app, but, by it's nature, really easy to extend.
    - steve_adams_86 5y ago
      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.

ChrisMarshallNY 5y ago

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.

kitsunesoba 5y ago
> 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.
- mwcampbell 5y ago
  > the framework would instead fill the gaps Might this be asking for patent trouble, though?
  - kitsunesoba 5y ago
    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.
    - ChrisMarshallNY 5y ago
      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. I have control issues, I guess... Everyone wants to write unique UI, but I've learned that's a trap. I write about that, here: https://littlegreenviper.com/miscellany/the-road-most-traveled-by/ https://littlegreenviper.com/miscellany/the-road-most-travel...
vouwfietsman 5y ago
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 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?
- ChrisMarshallNY 5y ago
armadsen 5y ago
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.

travisjungroth 5y ago

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.

ChrisMarshallNY 5y ago
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.
- krzat 5y ago
  > But usability is always reduced, in cross-platform systems. A native app is limited by capabilities of the platform. Perhaps Xcode is so bad because AppKit does not quite support the use case. On the other hand you have VSCode, a slow Electron app, but, by it's nature, really easy to extend.
  - steve_adams_86 5y ago
    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.