From Edison to Newton?

What can I say, I did not see this coming. Newton is back on the App Store. The news broke to me after reading a sceptical tweet written by Stephen Hacket that linked to an article in 9to5Mac.

Would I be willing to switch back to Newton? Instead of a straight answer, let me give a short recap of my client usage since Newton’s regrettable shut-down.

I’ve spent the Newton-less time period mostly using Edison Mail. Edison is a solid alternative, but no actual replacement. And it has it’s own problems. For example, the rendering of folder trees in my main account is seriously broken.

Over time, I also switched to using Outlook, Apple’s own, and – in times of desperation – even Airmail and Spark.

Airmail didn’t last longer than a a day, it’s still as buggy as it ever was. Spark made a mess out of a message I’ve got for confirmation of a Genius Bar appointment.

Seriously, this specific message rendered in Spark does not even look similar to what it looks like in any other client. It was not even possible to distill a calendar entry from what Spark presented me with. Who believes that such a behavior is a good idea?

On the bright side, my impression of was surprisingly positive. But it finally wasn’t able to muster enough gravity to keep me in orbit. Lack of sharing options, rendering of messages, no way to print a message1, just to name a few shortcomings.

One of the biggest upsides of Edison (and Newton, for that matter) is that it uses the space that it gets and renders e-mails such that they become actually readable.

I’ve got two exhibits as counter-examples: and Outlook. Especially the latter is the worst in this regard. On iPad, Outlook inexplicably uses only a small fraction of the available space to render messages, and the result in many cases is way too small to be comfortably read.

All that said, will I be spending money for Newton? Well, probably. I’ve got a couple of weeks on my existing plan2 before I need to decide about renewing my subscription. If the subscription rate were half the price it would be a no-brainer for me. But the current price makes me think twice.

On the other hand, with respect to my personal set of requirements against an iOS e-mail client, Newton does a near perfect job3, and (again, in my personal impression) none of the competitors comes close.

  1. Yes, in very limited cases I actually print e-mails. This happens mostly to get compensation for business trips using public transport. 
  2. For which I got a partial refund after Newton was officially taken down. 
  3. The new version of Newton comes with nice additions to the already impressive feature set. 

Automate storing of images with Pythonista and DEVONthink

One of my habits is to take a screenshot of my iPhone and iPad home screen on the first day of each month and store the screenshots away for further reference.

Until very recently, I used to store the screenshots somewhere in the file system.

I used to have a Workflow to store the screenshots into their respective directories. But at some point, the workflow broke on the basis of no longer being able to access an arbitrary directory in response to stricter sandboxing rules.

As a remedy to this issue, I considered adding the screenshots to one of my DEVONthink (To Go) databases. In this case, I would no longer have a problem with sandboxing and can still add the screenshots to separate folders inside of the DEVONthink database.

However, to make this possible I need to automate the process of adding of an image to DEVONthink. And this can – to the best of my knowledge – only be done by using the URL scheme for DEVONthink.

To celebrate the news that Pythonista is back in active development, I spontaneously decided to try to implement the storing of screenshots to DEVONthink using Pythonista1.

I learned a lot during this quest and found surprisingly little documentation about DEVONthink‘s URL scheme. Therefore, I figured it might be worth sharing my experience for the potential benefit of fellow DEVONthink users with a similar goal.

I started with one of the example scripts that implements access to the screenshots in my Photos library and modified it accordingly.

album = photos.get_screenshots_album()
screenshots = album.assets
if not screenshots:
    print('You have no screenshots in your library.')
    # Access latest screenshot
    newest = screenshots[-1]

I learned that Photos provides a „virtual album“ of all screenshots in your library and that this album is accessible (you guessed it) by calling the method photos.get_screenshots_album().

This call returns an AssetCollection, of which the last element (an Asset) is taken into further consideration in the form of the variable newest.

After – by way of accessing the element with the index -1 – achieving access to the latest screenshot, meta-data (specifically the creation date) are utilized to form the title of the screenshot in the DEVONthink database.

In order to not break the pattern of naming the existing screenshots, the title takes the form of a filename using a {yyyy}_{MM}.{imagetype} pattern2, even if it is stored in a DEVONthink database.

The year can be accessed by calling the creation_date.year property on newest.

    year = newest.creation_date.year
    month = '{0:0>2}'.format(newest.creation_date.month)

Setting the month was a bit of a challenge because the pattern asks for a two-digit month and the property creation_date.month returns just a single digit for all single-digit months.

Of course, this issue could be solved “quick and dirty”. But I wanted to find a solution by using str.format() with a fitting format string3. The result is shown in the code snippet above. I’m not sure whether this is the most elegant solution, but at least it works.

As mentioned before, I did not find any official documentation of the URL Scheme for DEVONthink, especially for the creation of images. After a round of searching, I found some hints in an article Federico Viticci at Macstories. That got me started.

Also, Gabe Weatherhead over at Macdrifter has documented some of his automation (mostly for adding markdown text) of DEVONthink.

The usage of any URL Scheme to pass an image to the database requires the serialization4 of the image in a URL-friendly form:

    img = newest.get_image_data(original=False)
    urlEncodedPic = urllib.parse.quote_plus(b64encoded)

In addition, it is also necessary to decide about the target folder to store the image. As mentioned before, screenshots for iPhone are stored in a different folder than screenshots for iPad.

In other words, it will be necessary to programatically find out whether the script runs on iPad or iPhone and select the target folder accordingly. To solve this issue, I posted a question to the Pythonista User Forum and quickly got a response: use platform.machine().

I’ve had an eye on this method before, but unfortunately was distracted by the documentation that mentioned ‘i386’ as a possible return value and that (at least in my personal understanding) suggests a hint about the architecture rather than the concrete hardware.

A deeper look at the chapter in the documentation might have revealed that there is also platform.architecture() and therefore platform.machine() very likely has a different purpose than to return machine’s architecture. Anyway …

    device = platform.machine()
    if (device.startswith('iPad')):
      destination = '58B06234-37B8-485F-AB7C-DC67CACFB9FB'
      destination = '71E35B25-466E-4E2A-AE2D-C65C4BAFB254'

This finally gets the last ingredient for the creation of the URL and its subsequent execution.

    url = 'x-devonthink://createimage?source={0}&title={1}&destination={2}'.format(urlEncodedPic,title,destination)

The argument named source passes the serialized image. The call to finally launches DEVONthink and adds the screenshot to the respective folder.

I have to say that this really works quite well and I’m very pleased with the result. Of course, the amount of time spent working on the implementation of the discussed script would probably be good for manually storing the screenshots worth of several years.

But that’s not the point. I learned a lot in the process and I may now be in a better position to solve further automation tasks with less effort. For example, variations of the script to handle photos or text rather than screenshots could easily be created.

  1. A possible alternative would have been to do the implementation in Javascript using Scriptable as the development platform. However, I know almost nothing about Javascript. My Python is better, but still not on expert level. ↩︎
  2. Where {yyyy} represents the four-digit year and {MM} represents the two digit month, with January being represented by ’01’. The {imagetype} boils down to ‘png’ or ‘jpeg’. ↩︎
  3. I’m a big fan of string formatting. ↩︎
  4. This means that the image is transformed into a sequence of textual characters form which the receiving end can reconstruct the original image. ↩︎


I had more or less given up the wait for another update of Calca, the markdown-capable text editor that can do math. It‘s been two years since the last update, with no support for the iPhone X screen in sight.

Last week, finally, that long-awaited update rolled in. According to the version history provided by the iOS App Store, the update comes with just two changes: support for iOS 11 (?) and the iPhone X‘s screen.

That seems … a bit … meager for the first update in two years, and I’d totally have some topics on a feature list that I’d like Calca to implement. But on the other hand, my wishes are mostly about usability1, as the core app is already crazy powerful.

I use Calca surprisingly often, it has earned a stable place on my homescreen2. It’s my go-to calculator for everything from dec-hex conversion, currency and VAT calculation, down to using the plot function to double-check my son’s homework.

And the best part is that you can write down the story of your calculation, with the calculation itself being an integral part of it.

  1. For example, a more powerful share functionality. At the moment, sharing a calculation is pretty much impossible apart from using the clipboard or mailing it via 
  2. A distinction that, quite frankly, no other app without iPhone X support ever managed to achieve so far. 

Instapaper saved

For the record, after a downtime of over two months, Instapaper finally became accessible to European users again1. Just when everyone was (rightfully) giving up hope for a happy ending, word came out that Pinterest is transferring ownership of the app to the developers who worked on the app during the Betaworks years.

In order to refinance work invested into the app by the new owners, Instapaper Premium makes its return in exchange for the same amount of money that the service charged before the acquisition by Pinterest.

Although I’m still a bit grumpy about the extended downtime I think I will become an Instapaper user again. Regrettably, the app hasn’t got much attention during the Pinterest years. I’d love to be convinced of the prospect of a brighter future by the advent of new features going forward.

  1. As a “token of apology” each user located in the EU gets six months of premium status for free. ↩︎

Newton to be discontinued

Out of the blue, Rohit Nadhani (CEO of CloudMagic) shared the sad news that Newton will be shut down on September 25th:

It was a tough business decision. We explored various business models but couldn’t successfully figure out profitability & growth over the long term. It was hard; the market for premium consumer mail apps is not big enough, and it faces stiff competition from high quality free apps from Google, Microsoft, and Apple. We put up a hard and honest fight, but it was not enough to overcome the bundling & platform default advantages enjoyed by the large tech companies.

For me, this is really a blow. In March, I’ve bitten the bullet and subscribed to Newton as a no-bullshit, straight-forward, and mostly stable1 e-mail client that delivered a significantly sized subset of my requirements towards an e-mail client.

And I liked it. It is (or soon will have been) the best e-mail client on iOS that I ever used.

I was hoping that the user base of (according to CloudMagic) 40000 subscribers was giving the developers a solid financial basis for working on the app going forward. But it’s not going to happen.

It’s sad to see this app disappear.

  1. The fact that this needs to be emphasized says everything about the state of iOS e-mail clients. 

Keep It

I’m not exactly busy searching for a replacement of DEVONthink (To Go) on my devices. Sure, I’ve been through some unpleasant issues with DEVONthink’s iCloud sync, ending up with the conclusion that I should stick to the older and more proven sync mechanisms for the moment. But still.

When I became aware of Keep It I wasn’t immediately thrilled, to say the least. Many years ago, I have been using Keep It’s predecessor, Together. At that time, Together was an OK Mac app which never got an even halfway decent iOS companion. Even back then, an app of this category was not acceptable for me without an iOS companion.

Fast forward to today: at some point, I decided to give Keep It a try in the most literal sense of the word: by activating the two-weeks trial period of the subscription required to use Keep It.

I have to say I like the design of the app and how well it integrates with the design language currently favored by Apple. However, the app is not as polished as you’d wish. For example, scrolling through a list of entries is not exactly smooth, even on contemporary hardware.

In contrast to DEVONthink, Keep It does not support different databases or different sync stores. It can only sync between devices using iCloud.

Before diving deeper into features that may distinguish Keep It from e.g. DEVONthink To Go, my primary goal during the trial period was to see how Keep It would hold up in very elementary ways (e.g. store, search, organize) in comparison to DEVONthink To Go and whether it could, in theory, replace DEVONthink for me.

Thankfully, Keep It supports the creation of folders inside the database which was an important feature for me in mirroring my current content of DEVONthink databases in an organized way to Keep It.

On top of moving stuff over, I used Keep It in parallel to DEVONthink, i.e. everything that I’d add to DEVONthink was also added to Keep It in order to compare the friction of working with one or the other app.

To make a long story short, the overall experience of putting my stuff into Keep It wasn’t exactly encouraging:

  • Files that had an extension in DEVONthink were given an additional extension on top of the existing one. For example, a file named file.pdf ended up as file.pdf.pdf.
  • File that did not have an extension were not properly recognized but just declared as having the type “data”.
  • The share sheet was unable to store imports in any other folder than the default import location. Files shared to a different folder simply never appeared in that folder.
  • Sometimes individual files would not sync between devices.
  • After sharing a file to the default import location it was not possible to move the file to a specific folder because the target folder inexplicably did not appear in the list of folders offered by the move action. Outside the move action, the target folder was perfectly visible and had all the expected content.

To summarize, I think I’ll pass and maybe have a look again after a couple of updates down the road.

Things Share Sheet, again

Hey, look at that.

A while ago, I have mentioned that the share sheet implemented by Cultured Code’s Things did not behave the way I would like it to behave. As a benchmark, I triggered the share sheet on Things’ own App Store page.

Today, apropos of nothing, I had a look at how the current version of Things is doing. To my mild surprise, the share sheet has improved.

In particular, the title part is now filled properly. However, the content of the title is repeated word by word at the top of the body part, for whatever reason.

It is hard to see what kind of sense this makes. The duplicate text would have to be removed manually, which can rightfully be called a bummer.

But don’t get me wrong, I appreciate any progress being made.

Instapaper down for over a Month

We look forward to having the same Instapaper service you know and love accessible in Europe in the very near future. Thanks for your patience.

Near future, eh? It‘s been more than a month, FYI.

I can’t believe that it takes Instapaper more than a full month to return to service if they really want to. I was never a fan of the acquisition by Pinterest and it seems that my initial skepticism was warranted.

Now Instapaper is just a small side-product that does not seem to get much attention any longer. I, for one, have given up on waiting for the service to return.

I haven’t finally decided about the replacement for Instapaper. And so my current approach for clutter-free reading stuff later consists of a mixture of using Pinboard in combination with Pinner/Pushpin, and the text extraction function in DEVONthink.

Logitech Slim Combo

The Logitech Slim Combo is a case for the iPad Pro that comes with a magnetically attachable keyboard. The keyboard uses the smart connector for communication with the iPad.

This comes with the benefit of not having to care for another set of batteries that – sooner or later – needs charging. Another benefit is that Bluetooth is not involved.

The obvious drawback is that the keyboard can only be used with an iPad in landscape orientation.

The Slim Combo also sports a handy loop for the Apple Pencil. The Pencil fits safely in the loop, no worries about accidentally dropping the expensive piece of periphery while walking around with the iPad attached to the Slim Combo.

So far, so good.

That name, though. If this is seriously considered the “Slim” Combo I really don’t want to see what Logitech would sell as the Bulky Combo.

That’s not to say that I dislike the solution. The case has to be thicker than other cases to house the surprisingly sturdy kickstand. I have used the Slim Combo every day for more than 5 months now and that kickstand didn’t get all wobbly at all and feels as new as on the first day.

The keyboard is OK, the keys are small and not exactly grippy, but I manage to do surprisingly good most of the time. The only thing that is really wrong with this piece of hardware is that fact that the lock key has been placed directly above the backspace key.

It is inevitable that the lock key gets hit from time to time. Put me down as not a fan of this design decision.

That said, I am a fan of the magnetic attachment to the smart connector. It is nice to be able to just rip the keyboard part off the iPad if it is not needed. And when reattached, there is no waiting period for the keyboard to reconnect.

In some cases I’ve witnessed weird behavior where I took the keyboard off the iPad and after some time wanted to quickly type something using the on-screen keyboard.

Which. Would. Not. Appear.

Whatever I tried.

The iPad clearly was under the impression that the keyboard was still attached and acted accordingly. I‘ve heard stories about weird behavior of the Smart Connector, however this particular behavior was never mentioned.

Thankfully, backlit keyboards are the new normal. And the Slim Combo does not make any exception. In theory, the backlight can be deactivated. But I never seriously used that option.

Most of the time I wish that the grace period between the last keystroke and the light switching off were a bit longer.

While considering the purchase of an external keyboard, I wondered whether I would really use it or whether this was one of the things that I “needed badly” only to discover after more or less short period of time that I’m actually better off without it.

However, these concerns are unwarranted. I use the keyboard nearly every day1 and I don’t foresee any change of this habit. I don’t even care about the added weight any longer.

In comparison to the other2 (Bluetooth) keyboard I bought a couple of years ago in combination with my iPad 4 the Slim Combo has already unlocked veteran status.

That other keyboard got returned to the Apple Store, mainly out of a concern that it sat very tight to the iPad during transport and might slowly but inevitably put scratches on the surface of the display.

There must have been a lot of complaints about real or assumed display damage in reviews of former products. There is no other explanation for the fact that the Slim Combo‘s keyboard keeps an almost laughably articulated distance from the surface of the display during transport.

Buying the Slim Combo was meant to be an experiment, after years of using the on-screen keyboard only. The (unexpected) outcome is that I don‘t want to use my iPad without an external keyboard for the foreseeable future.

  1. Even if it is only for cmd-tabbing through my apps. 
  2. I don‘t really remember the product name, only that it was also a Logitech design. 

Castro 3

For me, the podcast app Castro has flown mostly under the radar1. I’ve given it a try here and there because I really like the idea of building a podcast app around the central concept of a queue.

And yet, in each of these cases I dismissed it pretty soon because of a missing feature2 that other podcast apps offered and that I believed I couldn‘t live without.

According to Ryan Christoffel‘s review over at MacStories there is no need to worry about features any longer:

If an absent feature ever kept you from sticking with Castro 2, that almost certainly won’t be a problem anymore. Castro 3 addresses nearly all of those “one missing feature” requests in a single release. Trim Silence is Castro’s take on Overcast‘s Smart Speed; full chapter support is now present, as is a new Apple Watch app; the player screen has been fully redesigned; Mix to Mono improves stereo mixes that are hard to hear; and finally, there are excellent new per-podcast controls in a variety of areas. Perhaps the only thing still missing is an iPad app.

It is true, Castro 3 has caught up technologically with the more powerful podcast apps like, e.g. Overcast. On the other hand, Castro does have a few tricks up its sleeve that clearly sets it apart from a mere follower.

First and foremost, Castro is built with a focus on episodes rather then subscriptions. This is a, if not the fundamental difference to my currently preferred podcast player Overcast.

If you launch Overcast it displays a list of subscriptions.

If you launch Castro it displays a list of episodes in the so-called inbox.

From there it is possible to easily triage through the list of episodes and make an individual decision for each episode.

  • The episode can be played. This automatically adds the episode to the queue
  • The episode can remain in the inbox.
  • The episode can be moved to the queue, in which case there is the ability to decide whether it shall be added to the end of the queue or at the place below the currently playing episode. The queue is where the actual playing of the episode happens but moving an episode to the queue does not mean that the episode is starting to play in response to the move.
  • The episode can be moved to the archive. The latter has two roles, it represents the list of subscriptions3 and it also represents the back catalog of episodes.

The triaging of episodes does not necessarily have to be done manually. It is possible to decide for each individual subscription4 whether new episodes shall remain in the inbox and await triaging or whether they should be added to the queue (and if yes, whether they should be placed at the next position or at the end of the queue).

It is also possible to decide that each episode of a given subscription shall immediately be sent to the archive. This sounds weird, why should you subscribe to a podcast and at the same time decide to not care and send each episode automatically to the back catalog?

But that‘s exactly the use case: you may be subscribed to a podcast to which you don‘t listen regularly and only now and then skim though the back catalog if your queue is empty and there‘s nothing to listen to5.

Back to Overcast: I have defined only one playlist that (surprise, surprise) goes by the name „queue“. The subscription view in Overcast is segmented into subscriptions that have new episodes (titled “Podcasts”) and subscriptions without new episodes (titled „Played Podcasts“).

The existence of rules for the automatic placement of episodes into my „queue“ aside, I would then tap a subscription and then then decide whether to pick a new episode or one from the back catalog and add this episode to the playlist „queue“.

This procedure would typically be repeated for every single subscription, building up the „queue“ successively. However, my next step would then be to open the playlist “queue” and rearrange episodes in the preferred way6.

That’s right, Overcast does not offer a way comparable to Castro’s approach to influence the position of an episode in the “queue” right at the place where the decision about moving the episode to the “queue” is made.

If I decide to dismiss a given episode it is necessary to apply special care: Overcast uses the same trashcan icon for dismissing new episodes of a podcast subscription as well as for unsubscribing from the podcast altogether.

You have to be aware whether you’re in the list of subscriptions or in the list of episodes of a given subscription. I admit that I happened to confuse one with the other and accidentally unsubscribed from a podcast.

In Castro, you manage your subscriptions exclusively in the archive and there is hardly any chance for confusing the dismissal of an episode with unsubscribing from a podcast.

For someone who is subscribed to a larger list of podcasts the usage model implemented by Castro makes a lot of sense. In my personal opinion, Castro removes the friction in managing a large list of subscriptions according to individual preferences much better then Overcast can ever be hoping for in the current set-up.

Consequently, it should be easy to decide about making the switch and move over to Castro. In reality it is not that easy. And the reason for that is again a technological one.

Castro does not have any built-in sync mechanism7 and there is, as mentioned in the MacStories review, no iPad app. Personally, I use my iPhone to listen to podcasts between 90 to 95% of the time. Currently, I still have Overcast installed on my iPad and I use the ability to play podcasts on my iPad from time to time.

For all intents and purposes, it would not be a big deal to dismiss the lack of an iPad app and go iPhone only for podcast listening. But it still leaves the nagging feeling of missing out on something. Therefore, I’d personally like to see the advent of Castro for iPad.

To summarize, Overcast clearly is where the innovation happens in terms of podcast player technology.

But Castro innovates on its own turf while still providing state-of-the-art player technology.

In writing this article I think I have managed to convince myself to at least give Castro a longer period of time to see whether it sticks.

  1. Admittedly, it took me some time to stop wondering about the name. Maybe that’s becaue the name of most other podcast apps end with cast, and you might expect this pattern to apply of all of them. Castro makes a difference. 
  2. Last time, if I remember correctly, it was the missing support for chapters. 
  3. This is where you have to wrap your head around as a user of Overcast
  4. In Overcast, it is similarly possible to decide on a per-subscription basis whether new episodes of a given subscription are automatically added to a given playlist. 
  5. I subscribe to some podcasts that can have very long episodes of diverse topics. I am typically interested in at most a third of the episodes. But I appreciate the ability to easily access the back catalog and listen to one or the other episode whenever I like. 
  6. The rearrangement of episodes in Overcast can be finicky and I often need more than one try to finally achieve the intended placement. 
  7. There is the ability to create a backup and the app will (unless deactivated) create this backup automatically once a day.