Archive for January 12, 2017

Thursday, January 12, 2017 [Tweets] [Favorites]

100 Days Without the App Store

Bogdan Popescu:

All of Dash’s App Store revenue has migrated to direct sales, with a slight increase.


Dash for iOS was never a significant part of my revenue and like most iOS apps it was never sustainable. I should have open-sourced it a long time ago, as it now brings in more revenue by promoting Dash for macOS.


Dash for iOS returned to the App Store just a few days after I open-sourced it, thanks to He Tiancong and Jie Wang. This is despite the fact that I specifically chose a license that’s incompatible with the App Store. I highly recommend avoiding Dash on the iOS App Store, as I do not know what modifications they have made to my code.

Previously: Apple Removed Dash From the Mac App Store, Apple and Kapeli Respond About Dash.

Update (2017-01-12): Both of the iOS apps are called Dash and have the same icon. And one of them even uses Kapeli’s name. Apple’s reviewers should catch stuff like this.

Bad Uncle Leo:

@appstore did the same to @i0n1c over his App SysSecInfo. Other App clones w same functionality were approved. Just not his.

Update (2017-01-13): Bogdan Popescu (tweet):

Two more developers just released Dash on the iOS App Store as paid apps: Cuilian Su and Zuogen Zhang.

Apple Is Becoming HBO

Shira Ovide:

Apple is making the rounds in Hollywood, seeking to buy high-quality original TV series and perhaps movies. The idea is to supplement the Apple Music streaming song service with more digital video, the Wall Street Journal reported on Thursday. Think of Apple creating shows with similar quality and buzz to Netflix’s series “Stranger Things” but available only to subscribers who pay $10 a month for Apple Music.

Mitchel Broussard:

Apple executives have told Hollywood that the new original content will launch by the end of 2017, according to the new report. In terms of specific genres, HBO’s Westworld and Netflix’s Stranger Things were both used as comparisons for what Apple is aiming to produce on Apple Music. These proposed series and movies “don’t have any particular relationship to music,” unlike Carpool Karaoke and Vital Signs.

Zac Cichy:

Not that Sony is a bad company. But I think we could all agree that Apple becoming Sony would be very bad.

We live in an age where there is more good video content available than one could reasonably watch. But there’s only one good combination of a desktop OS and hardware, and it’s being neglected. Apple doesn’t have the resources and attention to make sure that PDF files work or that their customers have a good Wi-Fi experience. And of course there’s plenty of iOS and cloud work to do, too. TV and movie content seems like an unnecessary distraction. Apple should focus on the things that only they can do.

Update (2017-01-13): Dan Moren:

Granted, that might mean that those content providers are less enthusiastic about doing business with Apple, especially since their own shows would presumably take a backseat to Apple’s prominent marketing of its in-house efforts, such as in the new TV app that’s now front-and-center on Apple’s set-top box.

Six Colors’ 2016 Apple Report Card

Jason Snell:

“Apple TV has effectively stood still in 2016, despite needing significant attention in UI and remote design, performance, bugs, and reliability,” said Marco Arment. “Third-party apps and games have mostly failed to materialize, with Apple making no meaningful changes to address this.”


“I’ve been using Apple computers since 1980, and this is the first year where I feel like Apple is just another company rather than the computer that delighted me through all these decades,” said Brent Simmons. “It feels like Apple is no longer the company for people who make things.”

“This is a company that has lost touch with its users,” said Kirk McElhearn. “They’re harming their reputation with long-time users, they’re killing themselves in the ‘pro’ sector, where Apple used to be the main provider, and even ‘average’ users are starting to question whether it’s worth buying Apple products.”

Unlike much of the panel, I did not see a software quality improvement in 2016.

Previously: Apple’s 2016 in Review, Six Colors’ Apple Report Card.

Update (2017-01-12): Nick Heer:

From my perspective, Apple’s 2016 was uneven, at best. Unlike the panel, I thought the iPad had a pretty poor 2016: the 9.7-inch iPad Pro was introduced in the spring, and then it seemed like they forgot all about the iPad’s hardware and software for the rest of the year. My Apple TV gets lots of use, but mostly as a Netflix and YouTube box; very few streaming services are available in Canada. The Mac story is frustrating, and software quality is still rough. Over the course of many of the products and updates introduced this year, I’ve also felt that Apple has struggled to establish clear narratives and compelling rationales.

On a positive note, the reliability of Apple’s cloud services have noticeably improved, iOS 10 fixes many of my biggest complaints — while introducing some new ones — developer relations seem improved, and the company’s commitment to privacy is a particular highlight.

Static Typing vs. Testing

Robert C. Martin (Reddit):

My problem is that both [Swift and Kotlin] have doubled down on strong static typing. Both seem to be intent on closing every single type hole in their parent languages.


But before you run out of fingers and toes, you have created languages that contain dozens of keywords, hundreds of constraints, a tortuous syntax, and a reference manual that reads like a law book. Indeed, to become an expert in these languages, you must become a language lawyer (a term that was invented during the C++ era.)


Why are these languages adopting all these features? Because programmers are not testing their code. And because programmers are not testing their code, we now have languages that force us to put the word open in front of every class we want to derive from. We now have languages that force us to adorn every function, all the way up the calling tree, with try!. We now have languages that are so constraining, and so over-specified, that you have to design the whole system up front before you can code any of it.


All these constraints, that these languages are imposing, presume that the programmer has perfect knowledge of the system; before the system is written.

Drew McCormack:

Not in total agreement with the post, but quite a lot of agreement.

Joe Groff:

A type system is only as static as the code it describes. If you can change code, you can change types! The machine can even help you.

Chris Eidhof:

I don’t think it’s an either/or situation at all: we can have a solid type system and write “manual” tests.

A type checker actually does testing for you. It’s not a replacement for TDD, but it allows you to completely get rid of a whole bunch of tests.


In Swift, once you change foo to return an Int?, the compiler will now show an error for each time you call foo. This makes it easy to make that change, because until you have reviewed every single call to foo, the program simply won’t compile. I think of the compile errors as a todo-list, not as a speed bump.

Krzysztof Zabłocki:

I’m pro testing but I think this matches my thoughts exactly, almost anything you can do to get errors earlier in dev process is worth it.

I like both testing and types. The problem is that sometimes types get in the way. It would be nice to be able to do some work in a more dynamic style and then nail things down before shipping. That is the promise of type inference, but it’s not the reality of developing in Swift today.

Update (2017-01-12): Isaiah Carew:

i wish i could have both. static typing is really useful sometimes. really a burden other times.

David Owens II:

My main problem with Swift has always been this: far too pedantic about types and complete lack of a dynamic runtime.

Update (2017-01-13): Mark Bernstein:

Reading this debate, I was startled to realize one thing I’d overlooked: I almost never make type errors. I make plenty of errors – for me, programming is always about correcting errors – but type errors are once in a blue moon affairs.

I wonder if strong typing is a solution to a problem we don’t really have, or whether I’m just Doing It Wrong.

I concur. I think Swift’s optionals solve a real problem. The stronger typing, e.g. for collections, can make calling APIs more concise and help with auto-completion, but I don’t see this preventing many errors for me.

Update (2017-01-14): Robert C. Martin:

To be clear, and at the risk of being repetitive, that blog was not an indictment of static typing. I rather enjoy static typing. I’ve spent the last 30 years working in statically typed languages and have gotten rather used to them.

My intent, with that blog, was to complain about how far the pendulum has swung. I consider the static typing of Swift and Kotlin to have swung too far in the statically type-checked direction. They have, IMHO, passed the point where the tradeoff between expressiveness and constraint is profitable.


You might therefore say that the type system is a kind of “test” that fails for all inappropriate invocations of f. I might concede that point except for one thing – the way f is called has nothing to do with the required behavior of the system. Rather it is a test of an arbitrary constraint imposed by the programmer. A constraint that was likely over specified from the point of view of the system requirements.


So what the type system is checking is not the external behavior of the program. It is checking only the internal consistency of the program text.