Contents

• What happened?
  • The alternative suggested by Google wouldn’t work
• What happens next?
• How can I continue to access files in Google Drive?
  • Limitations
• What are the alternatives to Google Drive?
• Further Reading

What happened?

Google made some changes to the Google Drive API scopes and decided to classify some of them as “sensitive” or “restricted”.

Textastic includes file transfer clients for (S)FTP, Dropbox, WebDAV and Google Drive, which enable the uploading and downloading of individual files and whole folder trees, the creation of folders and the deletion of files and folders.

To implement file transfers for Google Drive, Textastic has been using the drive scope since version 6.1, which was released in 2016. This scope gives the app the ability to view and manage all files in a user’s Google Drive account.

The drive scope has been re-classified as “restricted” and Google has started to enforce this change for more apps, including Textastic.

In order to continue using that scope, Google requires me to complete a “CASA Tier 3 security assessment” for Textastic. This assessment is required annually.

“CASA Tier 3 is a comprehensive assessment that tests the application, the application deployment infrastructure and any user data storage location.”

According to Google, the “CASA assessment can take up to 6 weeks depending on how engaged and responsive you are in the whole process”. This assessment is conducted and validated by one of the CASA authorized labs.

The CASA Tiering website estimates that a tier 3 assessment takes 60 lab hours.

I contacted DEKRA, which is one of the labs listed by Google. They told me that the estimated execution time is 10 days, costing €9500.

Obviously, annual costs of this magnitude just to support Google Drive in Textastic are not sustainable - especially considering that there is no additional benefit for my business.

In addition to that, the lab staff would need “access to the development environment (user/password) for the application, access to source code, credentials and architecture documentation, etc.”, which I’m not necessarily comfortable with.

The alternative suggested by Google wouldn’t work

As an alternative, Google wants developers to switch from the drive scope to the drive.file scope. However, this scope would only allow Textastic to create new files and modify files created by Textastic.

It would not allow access to other existing files in Google Drive. So after connecting to a Google Drive account, the file list displayed by Textastic would be empty and the user would not be able to download any existing files.

There is also the “Google Picker API”, which would allow a user to pick individual files from Google Drive to share with an app. This API however is only available as a JavaScript library for web apps, not for mobile apps.

While it might be possible to use the Google Picker API in a web view, it does not allow the user to give Textastic access to folders. As a result it wouldn’t be very useful anyway since the same can be accomplished with the Google Drive app’s file provider and the iOS document picker.

What happens next?

For the reasons mentioned above, I have decided to remove the built-in Google Drive client from Textastic.

Google gave me a deadline of May 6, 2024.

Around that date, there’s going to be an ongoing 100 user limit for Google Drive connections added to Textastic and the Google Drive login will display an unverified app screen.

So even if your Google Drive connection is still working now, I don’t know exactly how long it will continue to work, but I expect it to start failing in May.

In Textastic’s next update, version 10.2, there will be a warning if you try to use or add a Google Drive connection, letting you know that it will eventually stop working. The warning will include a link to this post.

How can I continue to access files in Google Drive?

Please install the official Google Drive app on your iPad or iPhone. It includes a file provider, so you can enable Google Drive as a location in the Files app.

You can find more information in this Apple support article: “Use third-party cloud apps in the Files app”.

After adding Google Drive to the Files app, you can use the “Open…” command in Textastic to open individual files from Google Drive using the document picker.

To upload a file to Google Drive, you can use the share sheet. Alternatively, tap and hold a file in a file list in Textastic and select “Export” from the menu.

Limitations

Unfortunately, the Google Drive file provider doesn’t support opening folders, so the “Add External Folder…” command won’t work for folders in Google Drive.

Also, the “Create External File…” command will result in the error “Couldn’t communicate with a helper application” (com.google.DriveKit error 11) when you try to create an external file in Google Drive.

These are limitations of the Google Drive app’s file provider and part of the reason why I added a built-in Google Drive client to Textastic in the first place.

What are the alternatives to Google Drive?

Textastic supports iCloud Drive sync by storing files in its iCloud location.

There are also clients for Dropbox, SFTP, FTP, and WebDAV.

You can find more information in the manual: Connecting to Remote Servers.

Further Reading

Other developers are in a similar situation:

• Panels: Google Drive Integration Removal
• Total Commander: Google Drive access now only possible via own client id
• Moodle: Google Drive repo verification
• Google Workspace Forums: Drive API Auth Scope Changes
• Stack Overflow: Implementing the Google Drive File picker in iOS
• Reddit: End of Google Drive integration?
• Reddit: I gave up my Tier 2 CASA evaluation. This torture is too much for me.
• Google Issue Tracker: Google Drive Picker For iOS and Android

In this video you can see how this works:

These are the steps necessary to open a Git repository in Textastic 6.2:

• Make sure Working Copy is installed on your device.
• Tap on “Open…” in Textastic.
• Select “Working Copy”.
  
• Navigate to an existing Git repository or clone/initialize a new one.
• Tap on “Pick” to open the repository.
  
• The repository is now added as an external folder below the “Open…” command.
  

The external folder can be used just as “Local Files” or “iCloud”: You can edit existing files and add new ones. You can download and upload files. Web preview is fully supported. Changes you make will be immediately shown in Working Copy. You can then commit your changes in Working Copy. This works great in Split View mode on the iPad.

Textastic and Working Copy are both available from the App Store:

• Textastic
• Working Copy

Update: With Textastic 6.2, you can now open full Git repository folders from Working Copy in addition to individual files.

In this video I demonstrate the workflow:

In Working Copy, you can clone an existing repository from GitHub, BitBucket or your own private Git server. SSH, HTTPS and HTTP are fully supported. You can also create a new local repository in the app and push your changes to a remote server later.

Working Copy acts as an iOS 8 document provider, so that it appears as a location in the document picker next to iCloud Drive. It lets users open files directly from within another app like Textastic, editing them in place.

In Textastic, you can invoke the document picker using the “Open…” command which was added in Textastic 5.2. In the menu that comes up, tap on “More” to enable Working Copy.

After you select “Working Copy”, you can see a list of all repositories that you cloned or created on your device. You can navigate through the folders in your repository and select the file you want to open. Changes you make to such a file are saved in Working Copy’s sandbox and you can immediately see a diff when you switch from Textastic to Working Copy. Once you are done, you can commit your changes and push the new commit to the remote server.

Using the “Recent Files” list in Textastic, you can quickly switch between your most recently opened external files without having to invoke the document picker.

Textastic and Working Copy are both available from the App Store:

• Textastic
• Working Copy

This is the resulting shell script toggle_presentation_desktop.command:

#!/bin/bash

if [[ $(defaults read com.apple.finder CreateDesktop) = 1 ]]
then
	echo "enabling presentation mode"
	defaults write com.apple.finder CreateDesktop -bool false
	osascript -e "tell application \"System Events\" to set the autohide of the dock preferences to true"
	killall Finder
else
	echo "disabling presentation mode"
	defaults write com.apple.finder CreateDesktop -bool true
	osascript -e "tell application \"System Events\" to set the autohide of the dock preferences to false"
	killall Finder
fi

Make the script executable:

chmod +x toggle_presentation_desktop.command

Setting the “CreateDesktop” default to false hides the desktop icons, but still displays the wallpaper. The script uses AppleScript to hide the Dock.

Now I can just use Spotlight to execute the toggle_presentation_desktop.command shell script and it will toggle the Dock and desktop icons.

I also used Bartender to hide all menu bar icons except Spotlight and Notification Center.

This is one of the resulting screenshots:

Update May 26th, 2015: itc.cli does not work anymore. Please use codes from the fastlane toolchain instead.

itc.cli to the rescue! With the “iTunes Connect command line interface” it’s really easy to write a script that quickly generates a set of App Store promo codes.

Installing itc.cli

First, we need to install itc.cli. The installation instructions on itc.cli’s GitHub page didn’t really work for me. Here’s what I did:

Install pip and itc.cli:

# install Xcode command line tools (if necessary)
xcode-select --install
# install pip
sudo easy_install pip
# install itc.cli
sudo pip install itc.cli

If you later want to upgrade itc.cli, do this:

sudo pip install --upgrade itc.cli

Script to generate promo codes for three apps at once

Now, it’s very easy to write a script that downloads one promo code for each app. You just need to know your iTunes Connect login and the Apple IDs of your apps. itc.cli lists all apps and their Apple IDs when you log in. Here’s a (slightly modified) example output:

itc login -u <USERNAME>
Password:
INFO - Login: logged in. Session cookies are saved to <...>
INFO - Application found: "Textastic Code Editor for iPad" (383577124)
INFO - Application found: "Textastic Code Editor for iPhone" (550156166)
INFO - Application found: "Textastic" (572491815)
INFO - Nothing to do.

With this information, I could write this textastic_promo_all.command script:

echo "Textastic for iPad: " >> promocodes.txt
itc promo 1 -a 383577124 -o promocodes.txt -u <USERNAME>
echo "Textastic for iPhone: " >> promocodes.txt
itc promo 1 -a 550156166 -o promocodes.txt -u <USERNAME>
echo "Textastic for Mac: " >> promocodes.txt
itc promo 1 -a 572491815 -o promocodes.txt -u <USERNAME>

Make script executable:

chmod +x textastic_promo_all.command

Now you can just double-click on the textastic_promo_all.command file in Finder, enter your iTunes Connect password and it will automatically append three promo codes to a file called promocodes.txt - ready to send in an email.

The biggest hurdle was my use of JKParseOptionComments:

Allow C style // and /* … */ comments in JSON. This is a fairly common extension to JSON, but JSON that contains C style comments is not strictly conforming JSON.

Unfortunately, NSJSONSerialization doesn’t have an option to ignore comments in JSON files.

This is where my “NSJSONSerialization+Comments” category comes in!

You can use this category’s JSONObjectWithCommentedData:options:error: method just like NSJSONSerialization’s JSONObjectWithData:options:error::

id object = [NSJSONSerialization JSONObjectWithCommentedData:data options:0 error:&error];

The code is tuned for performance and works directly on UTF-8 data without converting it to an NSString. It strips single line and multi-line comments as well as whitespace before it hands over the data to NSJSONSerialization.

It also detects UTF-16 and UTF-32 through their byte order marks (BOM): if a non-UTF-8 BOM is found, it converts the data to UTF-8 using NSString. UTF-8 is definitely recommended if you don’t want this overhead.

I’ve also added a few convenience methods to load JSON from a file or URL instead of NSData.

More information can be found at the NSJSONSerialization+Comments Github repository.

When Mac OS X came out, Apple seemingly provided a high-quality template for document icons in their Aqua Icon Kit. According to an old MacRumors thread, a beta version of Icon Composer even included functionality to easily generate document icons.

Apple provides some useful information about creating proper document icons in the OS X Human Interface Guidelines. But, they don’t link to any templates or tools you can use to ease the creation of them.

On Stack Overflow I found that the generic document icon used by Mac OS X is located at /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/GenericDocument.icns. One should be able to use this as the base for custom document icons.

So, now I needed a way to access the individual images in an icns file. Sure, you can open the file in Preview, but as soon as you try to copy and paste one of the images into Photoshop, you’ll notice that the pasted image doesn’t include an alpha channel and all transparency information is lost¹. This isn’t very helpful. There’s also the “sips” command line tool, but it can only extract one png from the icns file or at least I don’t know how to make it extract all resolutions.

Thankfully, there is a solution if you have Xcode installed. Previously, you would create an icns file using the Icon Composer tool. The modern way, which also supports high-resolution icons for use with Retina screens, is to let Xcode create an icns file automatically from a set of png files in an iconset folder. Internally, Xcode uses the iconutil command line tool to create an icns file from an iconset folder. You can also use the iconutil tool manually and, even better: it also allows you to create an iconset folder with png files from an icns file!

Just use the following command:

iconutil --convert iconset GenericDocument.icns

This will create a GenericDocument.iconset folder which contains all resolution variants as neatly named png files - ready to be customized by you.