I read once that developers should stop focusing heavily on making their own lives easier and think more about making the user's lives easier, and the businessman in me agrees, and I think Apple is in the same court.

The sad part is Apple's market share is so great that to not support iOS is detrimental at best. Therefore Apple has us in a stranglehold: we're pretty much forced to support their platform, and they have no reason to make our lives any easier because we have no choice anyway.

That being said, though, I will probably still refuse to deploy any app I built personally to the App Store.

"You're holding it wrong" is not my version of making anyone's life easier, nor the slow but steady decline of their hardware.

OTOH, my mom figured out how to use an iPad and MacBook after struggling for years with windows PCs, so they are doing something right (or resting on the laurels of previously decent decisions).

You mention it yourself: there are hundreds of millions of people who use Apple products because they make their lives easier. If your software makes people’s lives easier, but you don’t offer it on that platform, you are not making those specific people’s lives easier.

> who use Apple products because they make their lives easier.

Cherry picking out of anecdotal evidence? I have read countless stories of Apple users who have had their beloved software broken by Apple updates. It goes both ways.

It doesn’t matter how many ways it goes: as long as there are people who use Apple products, and you are not providing your software to them, you are failing to make their lives better. Now, deciding if that is moral or relevant or whatever is an entirely different question, but I directly answered the one of “how are you making people’s lives better by developing for this platform?”

I have read countless stories of Apple users who have had their beloved software broken by Microsoft updates, and Windows bugs. It goes every way.

It depends on the software and market. My current job has native apps because they require hardware access not available to browsers. Another recent job was browser based only- our customers (businesses) needed their employees to use it, and did not want native apps because they knew getting everyone to install a company app would be a barrier to adoption.

In that sense, Apple fundamentally fails the "makes lives easier" bot again due to the extent to which they hold back the easiest-making platform (mobile web). From years old indexeddb bugs to penalizing the performance of websites saved to the home screen to slow-rolling other PWA features, Apple's success is a matter of history, marketing, and proprietary integration, not ease of use.

Apple's "walled garden" experience depends heavily on controlling as much of the software that gets into the user's hands as possible. Web applications just don't give them the control they want.

I wouldn't be surprised to find that if the app store hits some critical mass in terms of offerings that they decide to just get rid of a all mobile browsers. Christ I hope that doesn't happen...

I think most mobile operating systems are quite easy these days. An Android tablet isn't inherently more difficult than an iPad, except for the fact that there's no real Android competition for it (Android tablets are cheap and shit or expensive and with little support these days).

On the other hand, the last time I held an iPad it was because someone asked me to help them remove some apps from their tablet. I couldn't figure out how to remote anything because the little X that's supposed to appear when you want to uninstall something didn't show up. I was probably tapping it wrong (3d touch?) but I ended up giving it back and telling them to ask someone used to Apple devices.

There's a lot that iOS does right but there's also a lot that it does wrong. The same goes for macOS in my opinion.

The benefit macOS has is the same benefit ChromeOS has, in that it tries to show an interface with as few buttons and widgets as possible. There's a bunch of apps at the dock in the bottom and most people will probably never need more than that, aside from a decent browser maybe.

Windows tries to do the same but because it is Windows and people are used to button placements that have been the same since Windows XP, attempts at minimalism in the interface often meets friction. The Windows 7 control panel was, honestly, complex and difficult for many, but after so many years everyone who used it needed time to adjust to the new flatter, simpler design.

Microsoft tried to go the "make it as simple as possible" route with Windows 8, where they used the same paradigms on desktop as people were already using on mobile. This failed miserably and now they're doing a weird mix of keeping the old and reintroducing the interface for common programs every big update. It's a mess but I don't know what I'd do differently.

The sad reality is that now that Microsoft has lost the mobile OS wars, they'll never have the shared ecosystem they so direly need to properly compete with Apple. Their Xbox integration might prove to be a game changer here, though, because an Xbox and a few Windows PCs have the potential to compete with Apple TV and a few Macbooks.

or maybe windows was just terrible.

It isn't any more terrible than linux is terrible- which is to say that it requires a bit more practice and patience. Macos just happens to present the few things she uses it for front and center.

A chromebook would have suited her just as well if only it had enough hard drive space to store her pictures and was easier to connect to her iphone- one of those are not Apple's fault, one is.

Catalina highlights this as utterly untrue.

With a 47% market share in the US, I can hardly agree that supporting iOS won’t win you a lot of users.

Users != Money

As far as I'm concerned, you can sell desktop enterprise software for $500+ per license, but good luck trying to sell a $5 iOS app.

So even if it was 90% of the app market, it might still be financially better to ignore iOS and do desktop instead.

> but good luck trying to sell a $5 iOS app

i think the studies and evidence suggests that you'll have a much better time selling a $5 iOS app compared to $5 android app.

I don't really see how the two markets are even remotely comparable? If you're going to be selling $500/license enterprise software, its probably not suitable for phones. Likewise, there are whole classes of software that make the most sense as a phone app.

For me, the maker and distributor of the app, they cost similar amounts of money. So I need them to be similarly profitable, or else choosing the wrong one might ruin my business.

And while there are classes of software that make the most sense as a phone app, there are also classes of software that only make sense from an idealistic point of view, but not financially.

For example, the average indie phone game costs more money to make than what it'll bring in.

I would never try to build a business on either app store but even if you target the web you can't afford to ignore Apple, at least not in the U.S. On my last project Apple/iOS users made up half of our revenue.

Unfortunately this means it's hard to be a web developer these days without owning Apple hardware.

That's why he said:

if you're big enough where this really is an issue, then you can just afford a stand alone Mac who's job is to compile and test your app.

A lot of us are working remote these days. That means everybody needs a Mac.

*everybody needs ACCESS TO a Mac.

Exactly! Reason why websites such as https://virtualmacosx.com are a thing.

There isn’t a huge crossover between desktop apps and mobile ones. If you’re making a mobile app and you want to make money, you want to be on iOS. It’s been documented plenty that iOS apps make a lot more money than Android ones do.

iOS users = money

= you can afford to buy a Mac

Not disagreeing with that, but DiabloD3 was specifically talking users, not money.

This is nuts. If we broke mobile safari for our app we'd lose 50% of our traffic

If you are targeting US market with iPhone having 45% and increasing y2y, you cannot afford ignoring iOS and mobile Safari. What you can is not paying a dime for Apple hardware, though.

That's the developer perspective. As a user, macOS looks interesting due to the underlying UNIX, the consistent user interface and the high quality applications that are available. I've spend 200€ on Final Cut Pro X and it works very well. There'd have to be some really significant issues for me to switch.

PS: I develop but not on macOS and not for iOS.

> the consistent user interface

Have they fixed the utterly inconsistent way of moving/selecting words/lines since Snow Leopard?

Back then, depending on application I think you'd have to use ctrl-shift, cmd-shift, alt-shift or fn-shift to select words or lines of text depending on which application you used.

And yes, this inconsistency included their own software.

And yes, this is an honest question, I don't know the answer. I left Mac behind around 2012 because of a number of such things that kept wasting my time and my focus, but I enjoyed other parts of the experience and would be happy to pay (or get someone else to pay) for a premium non-Windows experience.

I think this part of macOS has always been consistent.

- shift- anchors the selection as you move the cursor and can be combined with any of the below.

- left/right jumps characters. (backspace/delete deletes characters.) up/down jumps lines.

- opt-left/right jumps words. (opt-backspace/delete deletes words.) opt-up/down jumps paragraphs (unless the app overrides this).

- cmd-left/right/up/down jumps to the edges of the document (unless the app overrides this).

- fn- and ctrl- are not typically used when editing text. In particular, the fn key is specifically used to invoke keys that are only available the extended keyboards, like home, page up, and forward delete. (Extended keyboards don't have the fn key.) I think there was a point where ctrl- did the same thing same thing as opt- or cmd-, probably as a convenience to users coming from other platforms.

Every single modern app has honored this in native text widgets since the first Mac OS X, I believe.

If you remember it being inconsistent, it's possible that you were using apps that use non-Cocoa UI like GTK/Qt/X11 (and possibly Carbon too). It might have been an app from Microsoft or Adobe, who seem to use their own UI toolkits. Or you could have been using a terminal app or developer tool with custom keybindings that didn't conform to these conventions. (VSCode, Atom, and Sublime Text's default keybindings do conform to this, and in Terminal and iTerm, there is a setting you can turn on to make the opt- modifer also conform.)

Which apps do you remember being inconsistent?

It is 8 years ago, so it is hard to remember exactly, but I found something on my old blog:

> Appendix: The hopeless keyboard addicts guide to the Mac keyboard:

> I was about to make a table here, detailing how to get at least home/end and pageup/down in the most used programs. But then some programs even differ inside of the program (like, "home" and "end" are mapped to different key combos depending on if you are located in the address bar of you browser or in a text area. This is especially funny when you've almost finished some writing on a blog, a company intranet etc, you want to select one line of text to move it around, and you forget that the key combo that means mark to start of line in one application means go to previous page in the browser. This particular one has hit me twice.)

> Here are a few hints anyway:

> - ctrl+a go to start of line. Works in almost every program, including terminal, but doesn't work together with shift.

> - ctrl+e go to end of line. Works in almost every program, including terminal, but doesn't work together with shift.

> - cmd + arrows/fn + arrows - may or may not works for either home/end. Depends on mood of programmer, moon phase when program was written or some other, unknown parameter. If one doesn't work, try another, they rarely do anything really wrong except triggering the web browser back action.

> ...

from https://techinorg.blogspot.com/2010/04/swithing-to-mac-one-y...

I'll admit that I haven't written anything about selecting words, and I don't trust my memory to be perfect, but I am also not sure I misremember that part. If it was only home/end I think I could have dealt with it by using shift-up/down.

Your opinion is popular and unfounded.

Until another platform performs better, I'll enjoy this bath like the boiling frog I am.

Pro: iOS users monetize more than Android.

Con: Pushing updates to an iOS app is a pain (review process).

I made a small puzzle game for mobile. It's free, with opt-in ads. I released it to both Android and iOS. It only got ~100 installs and didn't go viral or anything.

iOS somehow made 10x more than Android in ad revenue, which is to say, I made about $30 off of iOS ads, and $3 on Android ads. However, it was free to publish on Android, and $100 to publish on iOS, so actually I'm still at -$70 for apple and +$3 for Android. If your app doesn't make more than $100, it isn't worth publishing on iOS, even if your app is a public service.

In my experience they monetize like 500% better than Android users.

Not supporting iOS users is just baffling.

They're rich people plain and simple. They can afford $800 iPhones or $1,800 phone + iPad combos, to people who need to buy $200 Android devices.

Maybe I've been gaslit. But just don't push buggy updates. QA is not hard. Update all the time is a symptom of test-driven development, of affectless people who never use the software they make and look at their job description as, "cram algorithms questions, output git commits." The kind term for the right approach called "product oriented."

Test-driven development is a weird thing to blame for low quality.

There is certainly a false sense of security in test-only approaches. You only have tests for what you expect to go wrong, so every wrong assumption you make becomes a bug. Dedicated QA can help catch these, and are practically a requirement if your customers aren't content with things randomly breaking.

My previous job was just that... one QA person for a 50ish person team, focusing only on writing user acceptance tests. The leads thought that if we just had enough coverage, we could deploy continually without needing QA reviews, and were continually surprised at the number of bugs getting through.

That isnt to say that automated testing is bad, but rather that it is easy to be over-confident in what it will do for you.

>There is certainly a false sense of security in test-only approaches.

Assuming you mean automated-tests-only, then sure. But not only are full-stack approaches to testing encouraged by TDD best practice (i.e. unit to integration to e2e/BDD), it's also still compatible with doing functional QA, and I would recommend it. So I don't think we're in disagreement here, I think moderate amounts of functional QA and TDD are both parts of a healthy testing culture. (I'm a software testing and verification enthusiast, and formal methods have not yet exceeded the utility of these practices. When and if they do, I expect them to be far superior to both in most aspects, and fully replacing TDD with something like proof-driven-development.)

Not to mention that adding tests to a codebase vs starting with TDD from the ground up tend to result in pretty different results over the same time period; the former takes a longer time to start fully reaping the benefits.

Google Play allows for different "tracks" for publication: internal testing, closed alpha, closed/open beta, and production.

My approach is to keep releases in sync with Git branches (master is to production, staging is to closed alpha, etc). Although I don't often push things to master, I publish on any of these tracks at least once a day. I'm looking into the Apple ecosystem now, so I'm not sure if I can use a similar approach (my main concern is having a Mac as CI server).

If you already happen to be running Jenkins you can run an agent on the Mac and tag iOS builds to always run there. I’ve had decent experience with that approach, using Fastlane to build/upload different releases based on git branch like you describe.

Keep in mind you’ll need a graphical connection for occasional updates, which is likely different from the rest of the build system. You may also need it to fetch an Apple 2FA code every 30 days, that’s used to refresh your token to upload releases to App Store Connect.

> But just don't push buggy updates. QA is not hard.

I initially thought that you meant to just never write any buggy code, but I'm not sure that "just catch all the bugs in testing" is a whole lot more realistic. I guess maybe if your app is so simple that you can meaningfully exercise every part of it every time that you have an update?

I don't know; having recently submitted apps (and multiple updates) to both platforms, Apple consistently has updates approved within 24 hours (almost always much faster than that). The initial review for Google Play took nearly a week, and the messaging around its status was extremely vague and confusing. There's plenty of things Apple could do better around the developer UX for iOS, but the review process feels like the lesser of any of the evils these days.

The review process on Google Play is worse than iOS these days, both in regards to waiting time and in dealing with clarifications

People frequently overlook how nice the nix experience is on macOS. I had a new mac user complain about iTunes opening when they hit the play button like its some kind of conspiracy against him. I asked if he tried `sudo chmod -x /Applications/iTunes.app`. We tried it, and I don't understand why he was so surprised that it worked, and remained a permanent solution to his issue.

Your choices are the worlds most prevalent OS which is laden in telemetry and spyware by default, an OS that costs a fortune in hardware but comes backed by a company who has always stood behind their hardware mistakes (arguably after some period of denial each time), or to chose Linux. In this case, Linux means choosing from at least two variants* of distributions, and praying that everything works. I have an Intel NUC Hades Canyon that I run linux on, so that I always have a fallback if Apple significantly changes from their current course of treating users really well in exchange for a cash premium. First, my linux experience dates back to 1997/8 before the Linksys BEFSR41 ( the first hardware router under $300 ) became available, and installing a 56k modem or ethernet card meant re-compiling the kernel. Somehow, that was less painful than trying to get the amd gpu to work properly, and persist against breaking on updates and reboots. Yesterday, the author of i3, a window manager, shared a posting of his gear. I dug through his blog (cool stuff), and noticed on another of his posts that getting an amd gpu to work well on a debian distro was an issue for him as well. Again, I chose reference intel hardware expecting support for Ubuntu.

Being opinionated about design is not 'gaslighting' developers. And sure Apple is not perfect, I for one refuse to by a touch bar mac. I can't stand it, its annoying, and you have to pay extra for someone that for my computing preferences is a giant regression. But of the top 10 companies in the world (by market cap), which ones actually care about end users. Apple was started to put the power of computing in the hands of users, and they were damn successful at it.

Finally, in regards to Apple not caring about app development on their platform. Have you not used XCode? On the internet, you can find Steve Jobs demonstrating making a database driven application in 1989 using drag and drop components to design the UI. That is XCode, or its predecessor Project Builder. That is why Xcode Projects have files with the suffix pbxproj nestled within. Its all XML, and all of the build tools and chains are command line driven. You don't need to run XCode to develop an iOS app, but every year they add more and more of what developers want to it. Sometimes I wish that I could develop python inside of XCode, but I'm more than happy to stick with vim.

Swift and Swift UI are the real love letters to developers however. Swift, is open source, and runs on linux. Swift UI, is basically the react pattern of UI development, and they built it to solve the pain points of developers who were struggling with outdated development patterns on something that didn't even have color when it was first invented (Project Builder).

Sure, the iOS experience maybe too much of a "Disneyland" style experience of a great swath of the HN crowd. I for one love playing with Android phones that can run docker containers and X11 over USB-C. But at the end of the day, I am willing to pay extra money for a company that actually respects my privacy?

> I asked if he tried `sudo chmod -x /Applications/iTunes.app`. We tried it, and I don't understand why he was so surprised that it worked, and remained a permanent solution to his issue.

Now, if you had tried to do the same with pretty much any other app that shipped with the system you would be unable to.

You're right:

   $ sudo chmod -x "Font Book.app"/
   chmod: Unable to change file mode on Font Book.app/: Operation not permitted

   $ sudo chmod -x "App Store.app"/
   chmod: Unable to change file mode on App Store.app/: Operation not permitted

   $ sudo chmod -x TextEdit.app/
   chmod: Unable to change file mode on TextEdit.app/: Operation not permitted

   $ sudo chmod -x Reminders.app/
   chmod: Unable to change file mode on Reminders.app/: Operation not permitted

Doesn't even work on iTunes as the GP suggested:

   $ sudo chmod -x iTunes.app/
   chmod: Unable to change file mode on iTunes.app/: Operation not permitted

I’m not at my computer, so I gave myself a little bit of leeway: all the other applications are certainly on the read-only system partition so I know they are not going to change at all. Certain apps like Safari and iTunes are not on that as they can be updated, so I wasn’t sure if there was anything additional for those :)

ITunes doesn't seem to actually work either.

My apologies. That may have changed with SIP. A _fully optional_ feature that is great for security, and can be turned off if its too prescriptive.

A little disappointed to see the apple hate on this thread, especially as I spent the morning fighting with debian install on a raspberry pi to just have a clean upgrade. Again, these linux issues are much less common when dealing with linux on a server, meant to run a single program, or collection of production programs. But trying to maintain an ubuntu desktop is not without work, and Windows is loaded with telemetry and ads.

Apple puts users before developers which is why they have such a large market share. If you can't reach their high standards, just develop for another platform. There's no need to whine on HN about it.