Jim Edwards (via Dave Mark):
In 1981, not many people were writing software applications for the Apple II. Shelton was worried that the Apple Software Publishing group was promising impossible-to-meet sales numbers at the expense of quality. So Shelton decided to resign. “I’d already written my resignation letter with my opinions on the company’s direction and given it to one of my bosses, the head of the Apple II and III group, and had just given a copy to Mike Markkula — chairman of the board and VP of marketing — when I ran into Steve.”
[…]
The founder took him to Bandley 4 building and showed him what Steve’s secret group was working on next: The Mac prototype. […] “Would you like to be the product manager?” Jobs asked. Obviously, Shelton said yes.
[…]
Standing in front of his employees, Jobs told them, “we want developers to write small, efficient code, not Microsoft code.” His logic was that would metastasize all over the place. The [128K] limit would become Apple’s advantage by forcing developers to do more with less headroom.
Andy Hertzfeld Apple Apple II History Mac Steve Jobs Steve Wozniak
Brent Simmons:
Persistence was exactly as easy as that: you could get and set values and tables, delete things, etc., and the whole giant nested dictionary was stored on disk as a database.
This is exactly the kind of thing I want backing my Feed objects. I want a Frontier-like database with a table called feeds, and a subtable for each individual feed (keyed by feed ID). The table (remember it’s like a dictionary) for each feed contains exactly what it needs — including any arbitrary future stuff I haven’t needed or though of yet — and nothing else. No database migrations ever. Just room to grow.
Well — I’ve been working on this for a while, and it’s not quite done, but it’s close. See ODB, which is part of my RSDatabase framework.
Chris Lattner:
Glad to see that dynamicMemberLookup is useful to you! Hopefully you’ll like dynamicCallable too.
SE-0216:
This proposal is a follow-on to SE-0195 - Introduce User-defined “Dynamic Member
Lookup” Types
which shipped in Swift 4.2. It introduces a new @dynamicCallable attribute, which marks
a type as being “callable” with normal syntax. It is simple syntactic sugar
which allows the user to write:
a = someValue(keyword1: 42, "foo", keyword2: 19)
and have it be interpreted by the compiler as:
a = someValue.dynamicallyCall(withKeywordArguments: [
"keyword1": 42, "": "foo", "keyword2": 19
])
Previously: Exploring @dynamicMemberLookup.
Database Evergreen Frontier iOS Language Design Mac Open Source SQLite Swift Programming Language Syncing
Dan Moren:
For users, the benefits of choosing default apps is obvious. Right now if you tap a web link in most apps you get taken to Safari, regardless of whether you’d rather use Chrome or Firefox. The same for mail links: if you’d rather compose your messages in Outlook or Gmail, you have to jump through some hoops to make it happen.
[…]
Developers who compete directly with Apple’s built-in apps (like Mail, Safari, and Calendar) have always had an uphill battle ahead of them. How do you take on an app that’s installed on every single iPhone for free? Especially when your app will always be a second-class citizen. Allowing users to choose their own default apps won’t fix all of those problems, but it will go a ways toward making these apps viable for even more people.
Nick Heer:
Since you can now remove Mail, in particular, from iOS, this seems like it should be a natural next step. If you tap on a mailto: link without Mail being installed any more, you get an error message telling you that no apps are installed that can handle that type of link. But that’s awkward, confusing, and only partially true — no apps are available because no other apps are allowed to register themselves as capable of handling mailto: links.
Previously: Choosing iOS Default Apps.
iOS iOS 11
Rory Prior:
Then something went wrong. […] But over the last year or so it seems both apps have slid down (and down) the rankings until the point where they’ve become so buried I’ve started to regularly see days with low single digit, or even zero sales. When you’ve been selling apps for a decade and had previously been able to count on one hand the number of days you’ve had zero sales this sets alarm bells ringing very loudly.
It’s hard to overlook the major changes Apple made to the App Store with iOS 11 – search results are now extremely low density. You can barely see two results on a screen at once on a 4.7″ device, so if you’re say 40 or 60 places down your visibility is near zero. But that doesn’t explain my apps amazing fall down the rankings. In fact the most confusing thing is seeing apps which haven’t been updated in years – some of which look like first attempts at programming, with zero reviews, ranking tens of places above mine. What bizarre algorithm sees two apps with the same keyword, and ranks the one with no reviews that hasn’t been updated in 3 years above my 5 star one, updated a week ago?
Update (2018-08-06): Luc Vandal:
How can apps that weren’t updated for the past 4-5 years even show up first in the search results? What’s the incentive for developers to maintain their apps? Will search ever not suck?
App Store Business iOS iOS 11 Mac Mac App Store macOS 10.13 High Sierra Search
