Live data from Hacker News

The iOS and Mac markets are almost the same size?

inessential.com

91–100 of 120 posts

Re: The iOS and Mac markets are almost the same size?

#91
post #42

Earlier quoted context omitted.

What am I missing about BBEdit? I’ve tried to get into it a few times and it just seems archaic and weird and less capable vs even my emacs setup, let alone something like Visual Studio Code these days.

I'm a fan of vim, BBEdit, and Visual Studio Code, but "less capable than emacs" describes just about every text editor. While I'm using VSCode a lot more these days, I still like BBEdit a lot. It's a Mac-native programmer's text editor that manages to remain performant on large files. I think part of the problem is that in order to make a good programmer's text editor, you need a large community of people who're able…

> Visual Studio Code manages to attract enough developer attention to get people to work on compatible language servers

Not to nitpick an otherwise good argument, but the whole point behind LSP and language servers are that they are completely editor-agnostic.

A language server which enables great functionality in VSCode should be able to provide the same for other editors too.

Re: The iOS and Mac markets are almost the same size?

#92
post #26

Earlier quoted context omitted.

> Steve Jobs would be pissed Discoverability on the App Store has always been horrible. That, and App Store performance (search, page load, etc) are high on the list of things that baffle me most about Apple. These are not hard problems to fix. There is no incentive to not fix them. Customers are suffering. FTFAS.

> There is no incentive to not fix them. I think there is an incentive not to. If you buy Apple hardware, you are stuck with these stores. They know you will complain but ultimately comply and accept.

you mentioned zero incentive.

no incentive to fix =/= incentive to not fix

Re: The iOS and Mac markets are almost the same size?

#93
post #42

Earlier quoted context omitted.

What am I missing about BBEdit? I’ve tried to get into it a few times and it just seems archaic and weird and less capable vs even my emacs setup, let alone something like Visual Studio Code these days.

BBEdit probably isn't the best choice for code by modern standards, but it's super good at being a fast Swiss army knife for text. This is a frustratingly hard assertion to defend, at least in very short form, but I've been a technical writer for years now, mostly working in Markdown, and I keep coming back to BBEdit. It's not one huge thing that it does better for me than other editors, it's a collection of little t…

Going to check it out when I get the chance :)

I think studying old UX paradigms is super useful.

Re: The iOS and Mac markets are almost the same size?

#94

Earlier quoted context omitted.

I’m curious which features you would advise a dev to avoid in iOS, because their problems, i.e. toxicity. I’m getting more into iOS programming and it would be great to know some pitfalls on the roadmap.

Anything added after iOS 6 is the cheeky answer, but it’s not totally wrong either. Auto layout is incredibly hard to debug; it’s great when it works right, though, fwiw. The audio APIs are a garbage fire (equally on both platforms, at least!) Mapkit has a lot of sharp edges if you try to do anything more than Apple envisioned, which is true of a lot of iOS and macOS APIs. View controller transitions are a mess, but…

Ha ha, interesting.

To this I'd add major color defects that Apple has introduced with their (long, long overdue) ability to select a non-inverse ("dark") color scheme. For example, the segmented control, which is basically a radio button: You never know how it's going to be shaded or whether it'll be legible. Colors you specify in Interface Builder or even code are largely ignored.

The date picker is even worse, for the same reason. I have to programmatically check to see if the user's in "dark" mode and un-hide a light-colored rectangle behind the thing to make it legible. WTF. Apple finally added a method to override the user's color-scheme choice, but it requires iOS 13 or later.

Oh yeah: iOS has no drop-down lists. Apple forces you to use their ever-more-hideous spinner-wheel controls. Again, these largely ignore font and color choices, and require a ridiculous amount to space to make them usable.

Layout constraints are, for a long while at first, a baffling aggravation. They default to stupid things and report incorrect issues. But once you learn what they're really bitching about, you can make them work pretty well. The most valuable thing I learned about layout: Don't position things using hard-coded constants. Always position things in relation to their superview with "center horizontally" and vertically, then offset them with the multiplier. Then line up sibling controls to each other.

You'd think Apple would somehow facilitate gracefully expanding your UI with screen size, but they don't. The above method is really the key to doing so.

Oh, and their amateur-hour hard-coded resolutions for graphic assets, with the hokey @2x, @3x nonsense in the filenames... that's embarrassing. And you can't just use SVGs, like you can on Android.

All the quibbles aside though... I find the iOS development environment pretty damned well-done. And I like Swift a lot. Even Xcode has come a long way since Project Builder. Going back to Visual Studio, which I loved, I now find it suffers from some of the same defects it did in the early '90s and in some ways falls short of Xcode.

Re: The iOS and Mac markets are almost the same size?

#95
post #57

Earlier quoted context omitted.

In my experience, purely from a UX perspective (both visuals and responsiveness), a hand-crafted macOS app tends to be moderately better than an Electron app, but an Electron app is usually vastly better than a shoddy or cross-compiled native app.

In user interface, sure. Performance-wise Electron usually loses even to things like GTK.

Every GTK app I've ever used that didn't come with the OS (granted, I've never actually paid for one) is, compared to most electron apps, a) ugly/buggy, and b) feature-anemic, because it's so much less easy to add features to it. And as a user, I've never noticed a performance difference. I know Electron uses more memory and such, but it just doesn't impact actual usage in my experience. Whereas things not getting implemented because of developer friction absolutely does.

Re: The iOS and Mac markets are almost the same size?

#96
post #57

Earlier quoted context omitted.

In my experience, purely from a UX perspective (both visuals and responsiveness), a hand-crafted macOS app tends to be moderately better than an Electron app, but an Electron app is usually vastly better than a shoddy or cross-compiled native app.

A well-crafted, organic, gluten-free macOS app is generally the best UI and UX experience on any platform, by a mile. Apps that come to mind are Things by Cultured Code and (the as of yet unreleased to the public) Nova editor by Panic. No Electron app has ever even come close for me, certainly not VSCode that everyone seems to love so much. Then there's performance...

Agree with the first part.

But I would say the Slack UX, from a visual and performance perspective (not necessarily intuitiveness), is as good as nearly any native Mac app I've ever used. VSCode, from a visual and performance perspective, is better than any native Windows app I've ever used, and also as good as many native Mac apps.

I know people like to gripe about the memory usage and disk space usage of Electron apps, which, fine. But it's a fairly academic complaint. Those things don't honestly affect my experience as a user. The only time an Electron app has ever felt sluggish to me was Atom, fully loaded with plugins (~3 years ago), and I honestly suspect that had more to do with its naive and non-cooperative plugin architecture than with Electron itself.

Re: The iOS and Mac markets are almost the same size?

#97
post #42

Earlier quoted context omitted.

What am I missing about BBEdit? I’ve tried to get into it a few times and it just seems archaic and weird and less capable vs even my emacs setup, let alone something like Visual Studio Code these days.

I'm a fan of vim, BBEdit, and Visual Studio Code, but "less capable than emacs" describes just about every text editor. While I'm using VSCode a lot more these days, I still like BBEdit a lot. It's a Mac-native programmer's text editor that manages to remain performant on large files. I think part of the problem is that in order to make a good programmer's text editor, you need a large community of people who're able…

>"less capable than emacs" describes just about every text editor.

Fair, I think what I meant is that Visual Studio Code has more IDE features than my emacs does (I know it's possible to have more but things seem less stable when I start using LSPs and such), but BBEdit has even fewer than emacs.

Re: The iOS and Mac markets are almost the same size?

#98
post #42

Earlier quoted context omitted.

What am I missing about BBEdit? I’ve tried to get into it a few times and it just seems archaic and weird and less capable vs even my emacs setup, let alone something like Visual Studio Code these days.

For code, you’re probably right it isn’t all that great. But as text editor on the Mac it can do anything. What Photoshop is to images, BBEdit is to text.

>What Photoshop is to images, BBEdit is to text.

Yeah I get all these platitudes and stuff but I have used it and it doesn't seem more flexible than emacs here.

Re: The iOS and Mac markets are almost the same size?

#99
post #42

Earlier quoted context omitted.

What am I missing about BBEdit? I’ve tried to get into it a few times and it just seems archaic and weird and less capable vs even my emacs setup, let alone something like Visual Studio Code these days.

BBEdit probably isn't the best choice for code by modern standards, but it's super good at being a fast Swiss army knife for text. This is a frustratingly hard assertion to defend, at least in very short form, but I've been a technical writer for years now, mostly working in Markdown, and I keep coming back to BBEdit. It's not one huge thing that it does better for me than other editors, it's a collection of little t…

>BBEdit probably isn't the best choice for code by modern standards

Yeah, I think perhaps this is what I'm missing. I'm a software engineer and at minimum in an editor I want syntax highlighting and code formatting (completion is a nicety but still largely a hassle outside of IDEs) and it's just not there for the languages I want to use.

I definitely appreciate the "works like a Mac app" angle, although in many ways it feels more like a Mac app from 25 years than I would like. It doesn't feel modern.

Re: The iOS and Mac markets are almost the same size?

#100

Earlier quoted context omitted.

Same guy. 100% different project. He required the NetNewsWire name well after the start of this new open source RSS reader.

If it does the same thing and has the same name and creator, is it really a different project? Many software releases are actually complete rewrites under the hood. The only reason what became Net News Wire 5 originally had a different name is because NNW was owned by BlackPixel at that point.

>If it does the same thing and has the same name and creator, is it really a different project?

Yes? I don't even understand how this is a question.

>The only reason what became Net News Wire 5 originally had a different name is because NNW was owned by BlackPixel at that point.

From the post announcing the new name (https://inessential.com/2018/08/31/netnewswire_comes_home):

>You probably know that I’ve been working on a free and open source reader named Evergreen. Evergreen 1.0 will be renamed NetNewsWire 5.0 — in other words, I’ve been working on NetNewsWire 5.0 all this time without knowing it!

There's no evidence there is supposed to be continuity between the projects other than the name changing. You can say it's old school but the entire thing is written in Swift to modern UI standards. Not sure what more you could ask for.

Post reply on HN