Apple (PDF):
Today, economists at Analysis Group published a new report on the proliferation of third-party apps on the App Store, with new insights into how third-party apps perform in categories ranging from maps to music streaming, among others. The report finds that third-party apps experience broad regional and global success on the App Store, demonstrating the breadth of opportunity for developers and the wide range of choice available to consumers around the world.
[…]
The report analyzes apps from Apple and third-party developers across many popular app types, breaking down regional and global top performers. It also highlights just how many channels developers now have to distribute their apps — from mobile platforms, to PCs, to video game consoles.
So much competition, and they didn’t even mention the sweet solution.
Apple makes available a number of tools and core technologies to all developers to help them create innovative apps, including more than 250,000 software development building blocks called APIs.
Intellectual property for which they must be compensated.
Via Juli Clover:
The second part of the study focuses on the growth of the App Store over time (there are now 1.8 million apps), 99.9 percent of which are third-party apps as the study is quick to point out that Apple has just 60 apps that are competing with third-party apps.
The final part of the study focuses on the breadth of third-party apps that are available as alternatives to Apple-created apps, and it points out that for many categories like social networks, food, travel planning, and dating services, third-party apps are the only option as Apple does not compete in these categories. It also points out that across most app types, Apple’s apps are “eclipsed in popularity and account for a relatively small share of usage.”
Nick Heer:
Well that clearly does not add up. Spotify’s share in Japan cannot be “0.4 times greater” than Apple’s 55%.
[…]
Apple may have commissioned this study, but it does not appear to have done its authors any favours in getting them proprietary real-world metrics.
[…]
Does a combination of ad network partnerships and a sneaky consumption utility mean it is able to provide reliable figures on the use of, say, Messages or the Phone app? I find it hard to believe this is anything more than a best guess.
[…]
It sure is an interesting time for technology policy at government and platform levels. All the findings in this report are the result of choices made primarily by Apple in its design of iOS and the App Store. It seems there is healthy competition in some categories of apps and in some regions. But this report is not comprehensive. Third-party apps have limitations Apple’s own versions do not, and there are many other categories where Apple’s entrant likely pulls ahead — browsers would be an especially interesting case because, although it is one of two types of app where you can set a system-level default on iOS, any third-party browser will still use Apple’s rendering engine.
Macative:
Apple: if this huge competitive advantage didn’t exist in the first place, you would never need a study to point out that 60 apps is not a lot compared to 1.8 million.
It is a such pointless and insulting study, because at any time Apple can squash any app by making their own version, that is better, and is only better because it can do things Apple won’t allow the third party version to do.
Previously:
Antitrust App Store Apple iOS iOS 15 iOS App Spotify
BareFeats (tweet):
For the last three decades, Rob ART has been the Mad Mac Scientist, creator of the BareFeats website, where he combined his love of speed and Apple computers to report “Bare Facts on Mac Speed Feats.”
Robert Arthur Morgan pursued the TRUTH in all things APPLE/MAC with honesty, good manners, and unfailing fairness in his evaluations of products, whether great or small. His way of doing business and writing his BareFeats evaluations provided precious, rare, and valued information for manufacturers, business clients, and faithful readers. He tested Apple Products along with hard drives, graphic cards, and a plethora of accessories to make APPLE Computers run FASTER and meet the designing needs of Apple/MAC users worldwide with greater power, control, and efficiency.
Jason Snell:
My old boss at Macworld, Rick LePage, turned me on to BareFeats. It was one of those old-school Mac websites that was so clearly created by someone who was personally obsessed with a subject and just had to write about it. It was written in his voice, and was all about him chasing his own interests.
Mac Rest in Peace The Media Web
wenestvedt (tweet, Hacker News):
First announced on USENET in 1992, BBEdit has always offered powerful text-editing to Mac users. This week it turns thirty, and is still going strong!
Some of its features remain unmatched, like the great multi-file search. […] Syntax high-lighting, autocomplete, and the first regular expression engine I can remember on Macs (except for maybe Torquemada the Inquisitor?), and multi-platform file encoding have been helping Mac programmers and web developers for decades.
I’ve been using it since a year or two later, and I doubt there’s an app I’ve spent more time in. And let’s not forget the excellent documentation and customer support that go along with the app.
Previously:
Update (2022-04-15): John Gruber (tweet):
Eight years later I was working at Bare Bones Software. My lasting contribution: tweaking the user manual’s Grep chapter when BBEdit 6.something adopted the PCRE regular expression engine; theretofore it had been using a heavily modified version of Henry Spencer’s original library.
18 years ago I created Markdown in BBEdit, with the intention of using it from BBEdit. That’s worked out pretty well — just about every long piece I’ve written for Daring Fireball was written in BBEdit (including this one, natch). At that time, I considered BBEdit mature and well-established.
Update (2023-05-11): Today is the 30th anniversary of BBEdit becoming a commercial product. The company is celebrating by offering it on sale for $30 (Hacker News).
Update (2023-05-15): Gus Mueller:
I still remember discovering BBEdit 2.5 back in my college days, and was instantly hooked. I can even remember the office I was in when I started it up for the first time. BBEdit had this certain … way and feel about itself, it was 100% at home on the Mac and it was amazing.
Anniversary BBEdit Mac Mac App macOS 12 Monterey Regular Expression
Gergely Orosz (via Hacker News):
We are in the middle of the longest outage Atlassian has ever had. Close to 400 companies and anywhere from 50,000 to 400,000 users had no access to JIRA, Confluence, OpsGenie, JIRA Status page, and other Atlassian Cloud services. The outage is on its 9th day, having started on Monday, 4th of April. Atlassian estimates many impacted customers will be unable to access their services for another two weeks. At the time of writing, 45% of companies have seen their access restored.
For most of this outage, Atlassian has gone silent in communications across their main channels such as Twitter or the community forums. It took until Day 9 for executives at the company to acknowledge the outage.
[…]
For the past week, everyone has been guessing about the cause of the outage. The most common suspicion coming from several sources like The Stack was how the legacy Insight Plug-In plugin was being retired. A script was supposed to delete all customer data from this plugin but accidentally deleted all customer data for anyone using this plugin. Up Day 9, Atlassian would neither confirm, nor deny these speculations.
[…]
Atlassian can, indeed, restore all data to a checkpoint in a matter of hours.
However, if they did this, while the impacted ~400 companies would get back all their data, everyone else would lose all data committed since that point
So now each customer’s data needs to be selectively restored. Atlassian has no tools to do this in bulk.
Previously:
Update (2022-05-09): Atlassian:
There was a communication gap between the team that requested the deletion and the team that ran the deletion. Instead of providing the IDs of the intended app being marked for deletion, the team provided the IDs of the entire cloud site where the apps were to be deleted.
[…]
The API used to perform the deletion accepted both site and app identifiers and assumed the input was correct – this meant that if a site ID is passed, a site would be deleted; if an app ID was passed, an app would be deleted. There was no warning signal to confirm the type of deletion (site or app) being requested.
[…]
At the start of the incident, we knew exactly which sites were affected and our priority was to establish communication with the approved owner for each impacted site to inform them of the outage.
However, some customer contact information was deleted. This meant that customers could not file support tickets as they normally would. This also meant we did not have immediate access to key customer contacts.
[…]
Our full list of action items is detailed in the full post-incident review below.
Bug Tracking Cloud Datacide JIRA Outage Web
Core Intuition:
Daniel talks about finally moving from Mercurial to Git and the advantages of standardizing on technologies that have “clearly won.”
Core Intuition:
Manton talks to Daniel about his decision to switch from Zendesk to Help Scout, and gets Daniel excited about the prospect of finally switching away from FogBugz for his own work.
Core Intuition:
Daniel tells Manton about finally leaving FogBugz and going deep on Help Scout and GitHub Issues. Meanwhile Manton has also finished his migration to Help Scout! They talk about their mutual satisfaction with Help Scout and about how to best manage GitHub Issues.
For bug/issue tracking, I started out with FileMaker Pro, then CVSTrac, then Trac when I switched to Subversion, then OmniOutliner Pro. When OmniFocus came out it was a revelation, but ultimately it didn’t scale for the number of issues I had. I used FogBugz from 2009 until 2017 when I got fed up with the bugs and unreliability and the design got weird. Then I switched back to OmniOutliner Pro, which had improved a lot in the meantime in features, though I’m convinced that the interface brought back from iOS remains slower. This worked well for a while, but I kept running into scaling problems—particularly slow typing—even after splitting my issues into separate documents for each product and for current vs. archived issues.
Early this year, I did a trial with Gitea. Run directly on my Mac, it’s fast and works offline. I’m not dependent on a cloud service. The interface and feature set are good. It has an API and a command-line tool, and of course I had full access to the SQLite database itself if I wanted to do a fancy query. But, ultimately, I got annoyed by editing text within a Web app, and it was not as flexible with filtering, searching, and bulk operations as I wanted.
I’m now using EagleFiler, with each issue as a Markdown file, folders for milestones, smart folders for particular queries I care about, and tags for things like Area, Cause, Status, and Type. The GUID portion of each EagleFiler record’s record link is a natural identifer that I can put into code comments, Git commit messages, and other issues. The issues themselves are also in Git, so I get automatic backup, history, and syncing with my other Macs. Files related to an issue get attached to its note. When there’s a complicated issue that I want to work on, I open the Markdown file in BBEdit, where I get more editing tools and a live preview. I can automate things (like collecting release notes) via AppleScript and do bulk find/replace with BBEdit. In retrospect, it’s obvious that I would enjoy using my own native app, and that the app itself would benefit from such dogfooding, but for a long time I had a mental block about using it in my development workflow because there are times when it would be inconvenient to use the app as a tool while developing and testing it. So far, this has not been a problem. EagleFiler stores everything as regular files in folders, so if the app itself is unavailable, I can still browse/search issues using BBEdit projects or LaunchBar, tag them in Finder, etc.
For customer support, I’ve used regular e-mail (in Mailsmith, Apple Mail, and EagleFiler) except for the time I was using FogBugz. With FogBugz, e-mails got a case number so it was easy to link them from issues. Now, I do that using the Message-ID.
Previously:
BBEdit Bug Tracking Developer Tool E-mail EagleFiler FogBugz Git Gitea GitHub Help Scout Mac macOS 12 Monterey Markdown Mercurial OmniFocus OmniOutliner Programming SQLite Zendesk
