Posts

Posted on

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 Mail.app, 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 Mail.app 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: Mail.app 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. ↩
Posted on

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.')
else:
    # 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)
    title='{0}_{1}.png'.format(year,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)
    b64encoded=base64.b64encode(img.getvalue())
    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'
    elif(device.startswith('iPhone')):
      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)
    webbrowser.open(url)

The argument named source passes the serialized image. The call to webbrowser.open() 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. ↩︎
Posted on

Apollo 50

The Twitter account Apollo 50th is doing a great job by providing a detailed live-coverage of the events and communication of Apollo missions 50 years ago.

Currently on: Apollo 8.

Posted on

Castr…oh!

From the Supertop blog:

We have some news to share. Tiny has purchased a majority stake in Castro. We are still shareholders and will continue working on the app full time.

I would have loved to see Castro and Supertop thrive as an independent gig. On paper, this is good news because it means that the app will be more sustainable thanks to the financial support offered by the new majority stakeholder.

Castro has reached a size where the demands of running the business have been pulling us in too many different directions. We haven’t been able to focus as much on the core work of designing and building a product. Selling to Tiny gets Castro access to more resources, contacts and expertise. By growing the team we can specialize our roles to be more focused individually and get more done collectively. We can get back to what we’re good at and what we love doing.

On the bright side, this might get us the long anticipated iPad version. Who knows, maybe Castro 4 (that is also discussed in the article) will be released as a universal app. I certainly wouldn't mind.

Posted on

Pocket Casts 7 vs. Castro 3

The other day, a thought crossed my mind about whether I have an app on my iPhone where I have zero complaints about. After some consideration, I came to the conclusion that the app that comes closest to this ideal is the podcast player Castro.

Fast forward a couple of days, a new version of the rivaling app Pocket Casts was released and I just can’t ignore the release of a new (version of a) podcast player, even if I try.

I’ve been a user of Pocket Casts for some time and switched away for Overcast, and then for Castro 3. Would the new version of Pocket Casts be able to win me over again?

Triaging

Castro is the still unchallenged king of triaging. In my personal experience, Pocket Casts doesn’t even come close, even after giving Pocket Casts a fair amount of time to get used to.

In Castro, new episodes are added either to the inbox or – depending on your preferences – directly to the queue1. You’d tap an episode in the inbox and then one of the icons (add to the front of the queue, add to the back of the queue, archive) that become visible below. Tap again. Done.

This is a very efficient process because it is possible to keep tapping, instead of a mix of tapping and swiping – which is one possible approach to triaging in Pocket Casts.

Swiping left on an episode yields two buttons to place the episode either to the front or the back of the queue.

Alternatively, it is also possible to tap the episode, upon which a detail view opens. This view has a button to place the episode in the queue. Pressing this button makes two further buttons appear below the details view to decide about placing the episode to either the front or the back of the queue.

That’s three taps, and you’ll realize that you may have moved around your finger over the entire iPhone display to complete the insertion into the queue. This creates an unnecessary friction in comparison to the tap and then tap one row down in Castro.

It is possible to auto-add new episodes to the “up next” list in Pocket Casts as well.

Skipping Chapters

Pocket Casts supports the skipping of an entire chapter of a podcast episode (if it has chapters) via the remote skip button on my headphones.

On the other hand, Castro not only implements skipping to the next chapter via remote and lock-screen, it also supports this really sweet feature where you can plan ahead and uncheck single chapters in the chapter list where, by default, all chapters are checked initially. Unchecked chapters are skipped, simple and easy.

However, this is only possible for currently playing episodes and you have to remind yourself to actively switch to the chapter list and make your choice. But this ability makes a world of difference for me. This is a true “killer-feature” that came out of nowhere, and boy was it appreciated.

Sync

Castro is effectively a one-device app and does not synchronize to any cloud service at all. Pocket Casts, on the other hand, supports multiple devices on multiple platforms and thus implements a sync mechanism.

While, on paper, this ability may become a game changer for people on the fence between using one of the two apps, Pocket Casts simply does not deliver.

In my test of Pocket Casts, I was listening to a longer episode of a podcast on my iPhone. After finishing, I spent some time on the iPad (where I did not use Pocket Casts in this seesion), then returned to the iPhone to continue listening.

But instead of starting to play the next episode, Pocket Casts started playing the already played episode again, roughly at the point where I started the session before last.

I can only assume that the iPhone synched with the iPad while I was using the iPad, and Pocket Casts on the iPad managed to convince Pocket Casts on the iPhone that time stamp on the iPad was more current and thus the iPhone started playing the already played episode again.

Queue

Actually, my preference for queue-based podcast-players was created as a byproduct of using Pocket Casts for a couple of months some years ago. At some point, it clicked and I never looked back.

The new Pocket Casts puts the “up next” list (in terms of Pocket Casts‘ terminology) below the now-playing view, which is … weird. I don’t like it at all because this makes accessing the queue unnecessarily cumbersome.

The concept of a queue is front and center in Castro and the app focuses on removing friction from putting into and reordering episodes in the queue.

Switching from inbox to queue and back is just a tap in Castro. In Pocket Casts, you have to tap the “now playing” screen and then scroll down to reach the list of upcoming episodes. It makes some kind of sense, if you think about it, but it again creates friction.

From the list of upcoming episodes, going back to the list of new episodes requires just a single tap, to be fair.

Episode Downloading Behavior

It is possible to configure both apps such that episodes get downloaded only if they are added to the queue resp. the “up next” list.

At least that’s what I understand from configuring Pocket Casts‘ settings. In reality, it does not seem as if episodes are downloaded ever, at least according to Pocket Casts‘ own reports.

This behavior is a bit frustrating because I prefer to download episodes I add to the queue. This gives me control over when and where I make the decision and I can safely assume that episodes in the queue are downloaded and would not stop playing when I lose connection to the Internet while playing the episode.

Sound

As a basis for side-by-side testing the sound, I took a radio broadcast that is also distributed as a podcast. This way, there’s at least some probability that the audio has been produced with a professional background.

I activated all voice enhancements and silence skipping features offered by both apps because that’s how I use to listen to podcasts.

To my surprise, when switching between Castro and Pocket Casts back and forth on the same iPhone with the same headphones, I got the impression that artifacts became audible in Pocket Casts‘ output. I’m not an expert, but it seems to me that Pocket Casts may have a clipping problem. Castro delivered the same sequence flawlessly.

Back Catalog

The back catalog is another aspect where Castro shines. It is possible to subscribe to podcasts and still decide that new episodes do not even appear in the inbox and go straight to the archive. This way the episodes are easily accessible as part of the back catalog

Tapping on a podcast in the archive reveals the list of episodes. Played episodes are clearly marked as such and this makes a joy of going back into the back catalog and picking only unplayed episodes to listen to without ever accidentally picking an episode that was already played.

In Pocket Casts, there is also the concept of an archive. If I’m not mistaken, you have to unarchive an episode from the back catalog before being able to add it to the “up next” list with at least two additional taps. Friction, all the way down.

Conclusion

I tried to give Pocket Casts a fair chance of convincing me to switch. I try many apps, always on the lookout for improvements. And in many cases, I have left behind trusted workflows for something that just feels better and/or gives me an extended range of features over existing solutions.

But the verdict has never been clearer than in the case of Castro vs. Pocket Casts. Even though I see the lack of an iPad/Mac/web version of Castro as a real downer, I have absolutely no doubts that Castro remains the better alternative for my preferences for the time being.

  1. Auto-adding is not too important for me. I have only four podcasts out of more than 25 subscriptions that go straight to my queue. ↩
Posted on

Calca

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 Mail.app. ↩
  2. A distinction that, quite frankly, no other app without iPhone X support ever managed to achieve so far. ↩
Posted on

From Newton to Edison

As I already mentioned, the e-mail client Newton will be discontinued in just a couple of days. I had switched to it from Spark out of frustration about bugs and the opinionated design approach.

There is no perfect e-mail client on iOS. All available options are defined by their own individual composition of pros and cons. Newton is (or was) no exception to this rule.

Newton came out as my preferred choice based on the existence of unique features such as the ability to collapse single messages in a thread. It’s a small feature, but i loved it. No other app that I have come across has anything similar.

After the news about the discontinuation of Newton broke, I very hesitatingly started looking around for other options. As I thought I had a pretty good overview about the available options I wasn’t very optimistic to find a suitable replacement.

To my surprise, I discovered one app that had not yet appeared on my radar.

Enter Edison.

Edison was apparently created out of the ashes of another client that I have had a look at a while ago but wasn’t deeply impressed with. It was called E-Mail by EasilyDo at the time.

In many ways, Edison is the perfect successor to Newton. It supports a large portion of the features I used in Newton. The two apps implement a different design language1 but that’s fine for me.

In my experience, both apps are very stable and hardly ever show any bugs or unexpected behavior. That’s a big deal for me and sets both Newton and Edison apart for other e-mail apps that I have used before2.

Edison‘s sidebar is significantly wider than Newton‘s. To balance this, Edison comes with the ability to hide the sidebar and go full-screen. Newton does not have a similar option and also lacks Edison‘s ability to configure the different e-mail views and filters offered in the sidebar3.

On the other hand, Newton comes with some options to share a message, either to a collection of “connected services” or via the native iOS share sheet. If sharing is a must then Edison will not become your friend.

Literally, the only option for sharing is to invoke the iOS share sheet on selected text. I don’t understand why Edison is so limited with respect to sharing. It would be nice if this drawback could be removed in the future.

Newton has a bunch of special features branded as “superchargers”. But frankly, I do not care much for any of them, with the possible exception of the “snoozing” (which is meanwhile supported by almost any e-mail client except Apple’s).

Speaking of features, here is a short and subjective list of features that sets Edison apart from other e-mail clients I have used over the years:

  • In addition to the ability to mark an e-mail as read by means of a swipe it is also possible to simply drag the blue dot that identifies unread messages away from the message.
  • There is an “Assistant” section in the settings where active newsletter subscriptions can be managed. Also, this section offers a “Security” view that checks whether one of the configured e-mail addresses can be found in a list of known security breaches.
  • Notifications of incoming messages: I have seen other apps that would start to miss one or the other notification over time and eventually stop notifying of incoming messages at all. Edison is not one of those.

Edison is free to download and use. According to the support page money is made out of analyzing “commercial messages”:

To keep our services free for you to use, we collect and store information from commercial messages such as promotions and receipts. We remove any information that identifies you personally (emails, names, addresses), and aggregate it into research about ecommerce trends for businesses that purchase our Trends product.

It is possible to opt out of this analysis.

You control what data Edison can collect and store, with options to delete your data or to opt-out of our Trends product.

However, there’s obviously no guarantee that the switch to opt out really has any consequences. Naturally, I’m not very much in favor of such a “business model” and would much prefer to pay good money for Edison. But unfortunately, they wouldn’t take it.

Of all the existing alternatives, Edison seems to be the most viable for my personal requirements from the technical point of view. Whether I can live with the business model remains to be seen.

  1. Newton has a general grey tine that makes it appear calm and almost muted whereas Edison comes with a white background, blue accents, and bold typography that seems more at home in modern versions of iOS. ↩
  2. Airmail, I’m looking at you. ↩
  3. The options for configuring the sidebar are absolutely comparable to e.g. Spark or Airmail ↩
Posted on

Got my Beats X replaced under warranty. The headphones died on the third day of my vacation, roughly ten month after purchase.

Posted on

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. ↩︎
Posted on

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. ↩
Mastodon