How to find the UDID of your iPad or iPhone

Beta testing of iPad and iPhone apps is normally done via ad-hoc distribution, whereby the apps are distributed directly from developers to testers, instead of via the app store. However, because Apple normally only permits apps to be installed from the app store, it’s necessary for the developer to explicitly include a list of device identifiers in the beta version of their app, which allows the app to be installed on those devices. These identifiers, called UDIDs, must be registered with Apple; each developer is allowed up to 100 registered devices for testing purposes.

To install an app via ad-hoc distribution, you must send the UDID of your device to the developer. You can determine your UDID by plugging the device in to your computer, going into iTunes, and looking at the top of the “Summary” screen.

Initially this will show the serial number of the device, which is not what you want. To find out the UDID, click on the serial number and it will change to show the UDID instead. To copy this to the clipboard, control-click on the UDID and select “Copy”. You can then paste this into an email to the developer.


Can’t this be done from the device itself?


There used to be an app called Ad Hoc Helper which you could run directly on the device. It would retrieve the UDID and allow you to email it directly. However, in iOS 7, Apple introduced restrictions that prevent apps from determining the UDID, as it was being used by some apps to uniquely identify users for advertising purposes without their consent. While the change is a good thing for privacy, it means that Ad Hoc Helper no longer works (in fact it has been removed from the app store).

If you are a developer and receive a UDID from someone who uses the app, you’ll get what looks like a valid UDID but actually isn’t. iOS feeds a bogus UDID to the app, which begins with the string “FFFFFFFF”. If you add this to your provisioning profile, it will not work, as it’s not the true UDID of the device. The person installing it will either get an error message, or the installation will just silently abort once it’s nearly complete. So make sure that you only use UDIDs obtained through iTunes in the provisioning profile, and avoid any that start with ”FFFFFFFF”.

Coming soon: LaTeX support

The most important new feature in the upcoming UX Write 2.0 release is support for typesetting your documents using LaTeX. It’s been a major effort to implement this, and the full benefits will take some time to materialise (see below). Nonetheless, this sets the stage for a lot of great new features important for academic and technical writing, which will be added in subsequent 2.x releases.

I’m looking for beta testers for this release; if you’re interested, let me know.

What is LaTeX?

LaTeX is a file format and typesetting system designed for producing high-quality print output suitable for publication in books and academic journals. The file format is similar in nature to HTML; it can either be written by hand, or exported from a visual editor such as LyX. The typesetting system is based on TeX, which implements sophisticated typography including hyphenation, ligatures, and kerning, as well as beautifully-rendered mathematical equations. The result is print and PDF output that looks just great.

LaTeX has been the de-facto standard in many scientific and technical disciplines for decades. In the business world however, it’s not so well-known. But like switching from Windows to a Mac, or from working an office job to being a digital nomad, there’s just no going back once you come to appreciate the benefits. I’ve used LyX and LaTeX for my PhD thesis and all of my research papers, and like most people in my field, would never even contemplate anything else for a formal publication.

LaTeX comes to UX Write

From the very beginning, the design of UX Write has been driven by my desire to have something like LyX on the iPad. As much as I like the output of LaTeX, I don’t like writing the markup by hand; I find it much less distracting to have a visual editor where I can see headings, lists, bold/italics and so forth without special syntax. LyX does this on the desktop, exporting to LaTeX and producing a PDF identical to what you would get if you’d written the LaTeX source in a text editor. I’ve always wanted this same functionality in UX Write, but like most features, it involves an incredible amount of time and effort to implement.

Finally, after months of work, I now have a functioning port of LaTeX running under iOS, and integrated directly into UX Write. I’ll discuss the challenges I had to overcome to get this working in another post, but for now the key point is that this will be included in the upcoming 2.0 release.

First successful on-device typesetting run

The first successful on-device typesetting run

Why is this important?

Even if you’ve never heard of LaTeX before or aren’t obsessed with typography, this work is a huge step forward for UX Write because it lays the groundwork for many features people have been asking for but I haven’t been able to provide with the current WebKit-based PDF output. These include:

  • Footnotes
  • Headers and footers
  • Page breaks
  • Custom page layout
  • Cross-references to specific page numbers
  • Bibliography and citations

To be clear — these features won’t be in 2.0: the LaTeX integration has only been working for a few weeks, and I have a great deal more work to do in order to add all this functionality to the editor and convert these elements from the HTML (used internally by UX Write) to LaTeX syntax. And for the time being at least, LaTeX support will be export-only; parsing and conversion to HTML for editing is whole other story.

However, the hard part is now done, and you can expect to see these features gradually appearing in updates throughout the 2.x release cycle. In the initial 2.0 release (which will be a free update for all existing users) you’ll be able to get LaTeX typesetting with basic formatting for English documents, both when printing and exporting to PDF.

Tabs and multiple spaces

I often get questions about why UX Write doesn’t allow you to insert tabs into a document, or place multiple spaces after a period. Some people have also asked about why existing tabs in a Word document show up as a grey [tab] marker. In this post I’m going to explain why this is.

UX Write uses HTML – the language of the web – for displaying and editing documents. When you open and save a Word document, UX Write converts it to HTML and back again. The HTML content is displayed on screen using a software component called WebKit, which is the same layout engine as used by Safari (and formerly Chrome). Every document you edit in UX Write is quite literally a web page; the only difference with a web browser is that your document is stored locally on your device, not published online.

HTML provides a slightly different set of layout features to Word. While most features can be converted back and forth without problems, there are some features present only in HTML, and some present only in Word. Thus, UX Write can never provide a 100% faithful rendering of all Word documents, and doing so has never been a design goal.

I chose HTML partly because it’s so widely used – as the foundation of the web – and partly because it enabled me to use an existing layout engine, rather than spend years writing my own. HTML is also much better designed than Word, and with a minimal amount of training a person can reasonably read and write HTML code directly. This is not the case with Word documents.


HTML doesn’t support tabs. There’re simply not used not the web.

While I’m not sure of the exact rationale for the W3C (who designed HTML) to exclude tab support, I suspect the reason is because it’s unnecessary, in the sense that everything you can achieve with tabs you can also achieve without.

There are two main use cases I’m aware of:

1. Paragraph indentation. This can be achieved in both HTML and Word by changing either the left margin or text indent formatting properties of the paragraph or style.

In UX Write, go into the formatting menu and then either direct formatting or the style manager, and set these as appropriate. I recommend creating a style for the indented paragraph, so that you can do this again easily by selecting the style from the formatting menu, and later adjust the amount of indentation if you so wish.

2. Tabular data. This can be achieved in both HTML and Word by using tables, either with or without a border. Instead of adjusting tab stops, you adjust column widths. Instead of setting the alignment of a tab stop, you set the alignment of a table cell or column.

Even better, with tables it’s possible to create a custom style that defines the horizontal alignment, vertical alignment, and border appearance once and then use this for all tables in your document, so you don’t have to go formatting each manually.

Unfortunately UX Write doesn’t support customising table formatting at present, but this is coming in the near future. However, any customisations you make in Word will be retained by UX Write. I’m also considering providing the ability to convert tabs to a combination of indented paragraphs and tables when the app encounters a document containing these, so you don’t have to do so manually.

Multiple spaces after a period

By default, HTML collapses all whitespace in the source file, which means that any consecutive sequence of one or more spaces or newline characters in the HTML code is displayed on-screen in the same way as if there were a single space. If you view the source of a HTML document, you’ll typically see that a single paragraph is actually spread over multiple lines, e.g.:

<p>Here is a HTML paragraph. Its
content spans multiple lines in
the source file, for convenience of
editing in a text editor, but the
author's intention is to have it
displayed using word-wrapping according
to the user's browser window size.</p>

In a sense, HTML considers a sequence of space and newline characters simply as an instruction: “Don’t put the surrounding characters next to each other”. In fact, if you use justified text, the amount of space between different words will vary, as the layout engine will space the words out appropriately to ensure that both the left and right edges of all lines except the last line up with the left and right margins. In HTML, and most other file formats, spaces are not a fixed width character, and two spaces are considered no different than one.

While I’m aware of the controversy surrounding the “one space or two after a period” debate, I think it’s a pointless one. This problem was already solved more than 30 years ago by Donald Knuth when he created TeX, which automatically adds a small amount of additional whitespace between sentences, and gives higher priority to inter-sentence spacing than to inter-word spacing when it needs to stretch out a line when performing justification. If you really care about typography this much, you’ll already be using a system like TeX or LaTeX to prepare your final publication-ready output. The image below shows the same two sentences as typeset by LaTeX, Safari, and Microsoft Word; in all three cases, the text was entered with only a single space after the period.

Sentence spacing

The good news is that built-in LaTeX typesetting is coming to UX Write in the very near future. Most of my development effort over the past couple of months has been in porting LaTeX to the iPad, and when this work is complete you’ll be able to take advantage of the beautiful typographic output it produces when printing or generating PDF files, producing much more professional-looking results than is possible with Word. Stay tuned for more on this.

Why does typing two spaces insert a period?

The iOS text entry system has a built-in feature, which I believe is on by default, that allows you to type two spaces in succession to get a period, as a shortcut mechanism. This is an option which can be configured under the in the Settings app, under General > Keyboard > “.” Shortcut:

Period shortcut

While you can turn this off on a system-wide basis, the setting only applies to apps which use Apple’s built-in text entry mechanism (which most do). However, for apps like UX Write that provide their own text input handling, changing the setting has no effect. Unfortunately, to the best of my knowledge Apple do not provide any mechanism by which apps can determine whether this setting is on or off, so it’s not possible to automatically adjust the input behaviour based on this.

UX Write re-implements this feature itself, to match the behaviour seen in other apps when the setting is on. Before I implemented this, I received a number of complaints about the fact that it didn’t add the period after pressing two spaces, which is why I added support for it. Since then, I’ve received only a handful of complaints about the fact that it does add a period, so of the two options I’ve concluded that it’s better to have it on. This also seems to make sense given what I’ve discussed above about the inability (and pointlessness) of typing multiple spaces manually in a document.

Understanding Layout in UX Write

I sometimes get questions from people asking why some particular layout-related aspect of UX Write doesn’t work the same way as in Microsoft Word or Pages. The answers all invariably come down differences in the approaches these programs take to layout — that is, the way in which they display the text you’ve entered on screen, and the level of control given to you over how this layout is done. Because UX Write is based on Safari’s layout engine, its capabilities depend entirely on what is possible to do on a web page, which excludes certain features like tabs, page breaks, footnotes [1], and columns [2].

Microsoft Word, OpenOffice Writer, and Pages are all based around the idea of WYSIWYG (What You See Is What You Get). This is a visual approach to writing, where the position of text and other elements in the document is remains unchanged regardless of how you are viewing the document, whether on-screen or in print. This model is appropriate for people who need precise control over exactly how their final published document will look, and want to have that layout control combined with text editing facilities in the same program. If you have these needs, then UX Write is not a good choice for you as it specifically does not attempt to provide a fixed layout, for reasons I’ve written about previously.

UX Write, HTML, Markdown, LaTeX, and LyX are based around the idea of WYSIWYM (What You See Is What You Mean). This is a structural approach to writing, where you add text, sections, subsections etc. in an abstract manner, and the way in which they are actually displayed depends on the circumstances in which the document is being viewed. Often referred to as the separation of content and presentation, this model is appropriate for people who care only about the content of their writing, and are happy for the presentation to be tailored to suit the output device (tablet, phone, desktop, print), subject to some level of customisation (such as fonts and colours) defined in a stylesheet. If you have these needs, UX Write is really your only choice on the iPad right now — I’ve still yet to see another app which properly supports even styles, not to mention automatic numbering, table of contents generation, and other features that depend on structural information.

You use this latter model every day when you browse the web. Well-designed websites [3] will wrap their content to the width of your browser window or your phone/tablet screen, and this will change as you resize your window or rotate your device between portrait and landscape. On some desktop browsers, you can also change the font size to what is most comfortable for you to read. E-book software like iBooks and Kindle also follows this model. If you’ve ever tried to read a PDF document formatted for a full-size A4 page on your iPhone or iPad mini, you’ll undoubtedly have been frustrated by the small text and excessive scrolling; reflowable text avoids this.

Neither the visual or structural approaches are inherently “right” or “wrong” — everyone has different needs, and you should pick the app that’s right for you. UX Write is very much built around the structural approach, because it’s intended for long-form technical and academic writing, though is useful in many other contexts as well.

I realise now that the current messaging on the app’s website is too ambiguous — it compares UX Write to Pages, which I now think is a pointless comparison given that they’re designed for different types of users. I’ve actually found it quite a challenging task to communicate what UX Write is to an audience unfamiliar with the structural writing approach, and the app often gets judged badly when measured on those grounds. As part of a larger rebranding exercise I’m working on with a colleague of mine, I plan to redo the website to try and clarify the app’s focus on technical and academic writing, and make the differences from visually-oriented word processors clearer.

[1] Though they can be “faked”, like this

[2] Columns have actually been added recently to the web standards, but without pagination, placing an entire document in columns would cause the second column to start half-way through the document. The reader would need to scroll down the entire first column, then right back up to the top, before they can read the second column. That’s not good.

[3] And I don’t consider this blog particularly well-designed, though the latest WordPress update does seem to finally implement text wrapping when you resize the window, and it’s readable on an iPhone without zooming.

Moving Files and Folders

(or “Why File Synchronisation is Hard”)

One of the questions I get asked most often is why it’s not currently possible to move files or folders in UX Write. While this might seem like a very simple feature to add, there’s actually a lot more to the story, due to the need to ensure reliable file synchronisation in which no data loss can ever occur.

Normally, this is all handled by the operating system and third-party sync clients like that provided by Dropbox. However, Apple made the tremendously unfortunate decision to exclude any notion of a user-visible filesystem on iOS, so this isn’t possible. Desktop operating systems have had built-in file management capabilities for more than thirty years, and everyone who’s ever used a personal computer is familiar with the concept of organising their files into different folders.

While unnecessary for casual usage like browsing the web or playing games, file management is absolutely critical for content creation and management; its omission from iOS cripples the iPad as a productivity device. Nonetheless, it is possible for individual app developers to work around this limitation, but doing so is highly non-trivial in the case where synchronisation with an online file storage service is needed.

For the developer, moving files locally on a device is trivial to implement. There’s programming interfaces built in to the operating system to do this, and it’s a simple task to create a user interface for selecting the files to move and their destination. The difficulty lies in synchronising those changes with a server (or “The Cloud”, if you prefer that term) in such a way that guarantees no data gets lost in the process.

Clients and server

With online storage services, it’s possible to have multiple devices and people with access to a particular account. Software like the Dropbox desktop client, and UX Write itself, allow changes to be made to files while you are offline, and then later push those changes to the server. However, cases can sometimes arise in which different people have changed or moved the same file or folder while offline, and then later reconnect to the Internet and sync with the server. This is where things can go disastrously wrong, if conflicts are not handled carefully by the software.

An Example

Suppose Bob and Alice have access to a shared account, and are working with the same set of documents relating to a particular project. Both are working offline, when Bob decides to move a folder to a different location and Alice simultaneously makes some changes to a document inside that folder.

When they subsequently reconnect to the Internet, their iPad or PC will try to sync with the sever. Whoever happens to sync first will “win” and have their changes applied to the server successfully, while the “loser” will run into errors, with the server reporting that the folder doesn’t exist any more.

If Bob wins, the folder will be moved, but when Alice’s device tries to upload her modified version, it will encounter an error because the folder it was in no longer exists at its previous location. An incorrectly-implemented syncing mechanism may conclude that because it can no longer see a folder at that location on the server, it must have been deleted and that it should therefore result in the local copy being deleted as well — which happens to contain Alice’s modified document. The syncing mechanism would then see what appears to be a completely new folder on the server, and download that. But Alice’s changes would be gone.


File synchronisation is a complex topic, but necessarily has to be addressed to at least some extent by any app that lets you work offline with documents whose primary copy resides online. It’s unacceptable for an app to blindly push changes to a server without checking to see if the files or folders in question have been modified by someone else, and it’s also unacceptable for the app to download all changes from the server and overwrite local copies that may have been modified independently. It’s necessary to provide both conflict detection and resolution capabilities, with the latter preferably involving automatic merging of changes where possible.

There are many possible solutions to these problems, which have been implemented in various syncing clients and version control systems. Git provides what I consider to be the most elegant solution to this (plus a whole host of other things), but that’s another topic entirely which I won’t get into right now.

The simplest approach I’ve been considering for an initial implementation of moving is to do it synchronously — that is, require you to be online at the time of the move, and wait until the server has reported a successful completion of the operation before allowing you to continue using the program. In computer science terms, this is known as an “atomic test and set” operation, where a check is performed to see if the change is valid, and if so, the change is made, all in one indivisible operation, avoiding race conditions. The alternative is to perform the move asynchronously — that is, in the background at a later point in time; but that has all the problems mentioned above, and requires keeping track of lots of extra information in order to do it reliably.

In the long term, I plan to integrate support for Git directly into UX Write, so you’ll have access to its full set of functionality, including versioning, branching & merging, and conflict resolution. Software developers use this all the time for collaboration, and I’d encourage you to learn more about it if you’re interested. I’ll be posting more about this integration in the future once I’ve had a chance to think it through further.

Doesn’t iCloud handle all of this?

Sort of, but only in the context of a single application and a single user. Since UX Write only runs on the iPhone and iPad, many people use it in conjunction with other applications like Microsoft Word on their desktop, so it’s necessary to sync the files between different platforms. iCloud has a restriction that only allows files to be accessed from within the application that created them, and provides neither a generic filesystem model of the sort found on Mac, Windows, or Linux, nor does it cater for the need to edit a given document with different applications. So that basically rules it out, as far as I’m concerned.

In Summary

Better file management facilities are coming to UX Write, but as described above these aren’t straightforward to provide in the context of the ecosystem we have today where everything is stored and synced online across multiple devices. At the moment, my primary focus is on building a word processor, not a file manager, so the latter has secondary priority. But I am very much aware of the need for improvements in this area, and will get to them eventually.

Content, Structure, and Presentation

UX Write is designed around three primary aspects of electronic documents: content, structure, and presentation. To appreciate how and why the app works the way it does, it’s important to understand each of these aspects and how they relate to each other:

  • Content is simply the words and images in your document — nothing more, nothing less. It is the most important aspect, because it contains the primary value — your idea, your story, your message; whatever information you intend to convey to the reader.
  • Structure is the way in which your document is organised. Typically this involves a hierarchy of sections with one or more levels of headings, as well as the arrangement of content into paragraphs, lists, tables, and figures. Any special designation attached to certain paragraphs, such as the document title or a footnote, is also considered structure.
  • Presentation is what your document looks like. It is determined by formatting and layout options such as fonts, colours, margins, and line spacing. These options are either set on a case-by-case basis via direct formatting, or, preferably, using styles to specify how headings, normal paragraphs, and other structural elements should appear.

All three of these are critical aspects of any professional documentation tool; when tied together, they permit the automation of many editing and publishing tasks. Structural information, in particular, is necessary for generating a table of contents, numbering headings, figures, and tables, supplying the text of cross-references, and providing navigational aids during editing such as an outline view. Furthermore, the use of styles enables the presentation to be based on the structure, so a consistent visual design can be reliably maintained throughout the whole document without manual effort.

Word processors vary greatly in their support for the structural aspects of editing. Some provide none at all — requiring all presentation to be specified via direct formatting, which makes it difficult to achieve a consistent look and feel or conform to organisational style guides. Others provide very basic facilities, such as lists and tables, but little else. The most capable provide full support for all aspects of structure, such as headings, built-in and custom styles, automatic numbering, and table of contents generation.

Even when a word processor supports advanced features, they are not always obvious from the user interface, and are only revealed in their full glory after you’ve climbed a steep learning curve. The canonical example is Microsoft Word, which has hundreds of features hidden away in various menus and dialog boxes, but has a default toolbar configuration which encourages bad practices like direct formatting, as I discussed in a previous post.

UX Write is designed first and foremost for structured writing, with the hierarchical organisation of sections made explicit, and direct formatting deliberately discouraged in favour of styles. This is why it feels so different to use than Word — it’s a cleaner, more disciplined approach to document authoring, which is optimised for writing, with presentation as a secondary concern. The focus is on helping you with your most important task — getting your message across.

iOS 7 Update and New Features

iOS 7 has finally been released today, and with it the first set of apps updated for the new version of the platform. Among them is a major new release of UX Write, which addresses language support, and adds several important new editing features. UX Write 1.2 requires iOS 7, and will run on the iPad 2 or later, iPad mini, and iPhone 4 or later.

Here’s what’s new:

User Interface Localisation

All menus, dialog boxes, and other user interface text have now been translated into the following languages: Chinese (Simplified/Traditional), Dutch, French, German, Italian, Japanese, Korean, Portuguese (Brazil/Portugal), Russian, Spanish, and Thai. The translations are thanks to the excellent work of LocalVersion. More languages will be added in the future.

UX Write in Thai

Text Entry in Chinese & Japanese

Keyboard-based text input mechanisms for east-asian languages require multiple key presses per character, due to the existence of many thousands of possible characters. For example, to type 中国 (the Chinese word for China), you would type the letters “zhongguo”, and then select from a list of candidate words from an extra row on the keyboard.

Chinese text input

Previously, UX Write operated under the assumption that every key press corresponded to an individual character, which is true of European languages, but not of Chinese or Japanese. There are also handwriting-based input mechanisms for these languages built in to iOS where you don’t press keys at all.

Luckily, Apple already provide all of the keyboard logic for taking this kind of input from the user, including the word choice mechanism described above. However, apps like UX Write which use custom text editing components have to explicitly cooperate with this logic by supporting so-called “marked text”, which is the sequence of letters that has been typed by the user, but is “provisional” in the sense that it will later become a different sequence of characters when you finally choose a word. It was this relatively small piece logic that UX Write was missing, and now that I’ve added support for this, the key-based and handwriting-based input mechanisms for Chinese and Japanese now work.

Find & Replace

You wanted it, you’ve got it. This has been the most requested feature of all over the past few months, and is finally in. You know that empty space at the top of the toolbar where other apps put direct formatting properties like font size and paragraph alignment that really belong in styles? I’ve used that space instead for a search bar — just like you have in Safari. Just tap on it and type in your search term. On the iPhone, it is accessible under the Settings menu.

Find and replace

If you tap the little arrow icon next to this bar, you’ll get some additional options. You can use these for find & replace (as opposed to just find), specifying whether to perform a case-sensitive or case-insensitive search, and also searching based on regular expressions. [see note at end of this post about a replace bug for which a fix will be available in a few days]

Regular expressions, if you haven’t encountered them before, are a way of specifying patterns of text that you want to match, rather than an exact match of a particular word or phrase. UX Write supports regular expressions in both the search text and the replacement text. If you’re an old-school Unix hacker you’ll be familiar with the concept; otherwise, you can learn about them here. UX Write’s regular expression support uses the NSRegularExpression class that is part of iOS; you can see the details in all their glory on Apple’s developer site.

One suggestion a beta tester made to me was offering a “whole words only” option for find & replace. I’ll be providing this in a future update.

Spell Check

Another often-requested feature, this is now available as well. You can access it from the Settings menu, and it will highlight any words it finds that aren’t in the dictionary. The user interface for correcting a word is the same as what you use for autocorrect — you can select from a list of alternatives, or add it to the custom dictionary (which can also be edited through the Settings menu).

One caveat with spell checking in UX Write is that it only works with languages for which Apple provides a built-in dictionary. These languages are: Danish, Dutch, English, French, German, Italian, Portuguese, Russian, Spanish, and Swedish. If Apple later start including dictionaries for other languages, then these will be automatically supported for spell checking and autocorrect purposes by UX Write.

Word Count

There’s not really much to say about this I guess other than yep, it’s there.

I did find out however rather late in the piece that Japanese is written without spaces between words, and I’ve been told that in Chinese spaces are often omitted as well. Thai is the same; I’m actually studying Thai at the moment and while the books we’re using in class use spaces between words to help us comprehend sentences more easily, this is not done for mainstream Thai writing.

So for now at least, word count only works properly for languages in which words are separated by spaces. However, it does also show the total number of characters and paragraphs in the document as well, so if either of those is what you’re after, you can get them as well. I’ll be adding an extra item for character count excluding spaces in a future update.

iOS 7

The release of iOS 7 is one of the most significant in the platform’s history, after the introduction of third-party apps in 2008, and multitasking in 2010. While on the outside there’s a complete visual refresh, there’s also a lot of new features “under the hood” that I’ll be taking advantage of in future versions of UX Write.

One of those in particular is real-time pagination in WebKit, which will allow me to provide an option in UX Write that will show you where page breaks will occur in the printed document. A lot of people coming from an MS Word background have been asking for this, but I haven’t been able to provide it to date due to limitations in WebKit. Unfortunately, the pagination support in the initial release of iOS 7 doesn’t work correctly, so I have to wait for Apple to fix the bugs I’ve reported before I can make use of it in UX Write.

Other new features I plan to utilise include improved background file transfer, AirDrop support, and CSS regions (enabling magazine-style page layout). I’ve really only scratched the surface of what iOS 7 has to offer at this stage, because all the beta versions of 1.2 had to be compatible with iOS 6 as very few of my beta testers have developer accounts.

Now that iOS 7 is available to the public however, new releases of UX Write from now onwards will depend on it. While I’ve been reluctant to drop support for older versions — particularly because iOS 7 won’t run on the original iPad — I’ve concluded that the effort required to support both is too much to be worth it, and I’m better off putting my time into adding new features. If you have an iPad 2 or later (including iPad mini), or an iPhone 4 or later, you can update to iOS 7 for free.

Known Issues

There’s been a lot of “behind the scenes” changes in the UX Write codebase for this version which won’t be readily apparent to you as a user, but have increased the risk of bugs in this version. It’s had a fair amount of testing while in beta, however there are several issues that have come up since I submitted 1.2.0 to the app store a week ago:

  • When opening an existing Word document that doesn’t already contain heading styles, these will not show up in the formatting menu. If you encounter this problem, open up the document in Word, mark one or more paragraphs using the heading styles you want, and then take the document back to UX Write.
  • The external keyboard is not recognised in some cases. If this happens, just tap on the screen and this should get it to recognise the keyboard.
  • The replace field doesn’t work on the iPad. Currently there’s no workaround for this; it only works on the iPhone. Yes, this is a bit embarrassing.

I’ve already fixed all three of these bugs (plus a few others) and submitted a 1.2.1 update to Apple. It should be approved for release in the next few days. Do let me know if you find any other problems.

Update (19 September): Apple approved the 1.2.1 update in just over 24 hours. Normally it takes 4-5 days; I’m impressed!

WWDC wrap-up

It’s been a pretty amazing week for me here in San Francisco, attending WWDC 2013. This is my first time at the conference (and my first time in San Francisco, or the US for that matter), and I’ve really had an incredible time meeting some great people and experiencing some of the energy here.

There were basically two main parts to the conference – sessions on new features in iOS 7 and OS X Mavericks, and the labs in which developers have the opportunity to sit down with people from various engineering teams within Apple. My primary focus of course was on WebKit, as this is main the part of iOS that UX Write is built on. I had the opportunity to talk with some of the team about new features that have been introduced, and work through a few issues I encountered – which has been extremely valuable.

WWDC - Keynote Lineup

Much of what was covered during the conference is subject to a confidentiality agreement that all developers are required to comply with, so unfortunately I can’t give details about the new features other than what was discussed in the keynote. The session videos and all new documentation & SDKs are, however, available to all registered Apple developers (and, presumably, NSA contractors). What I will say is that there are some very exciting capabilities coming in iOS 7 that are going to enable me to provide certain features in UX Write that I haven’t previously been able to, and I’m very much looking forward to taking advantage of these. Once iOS 7 is out, all future updates to UX Write will depend on it, so at that point you’ll need to have it installed (iOS 7 will run on iPad 2 and later, as well as iPhone 4 and later).

The atmosphere was electric

Take 5000 developers from all around the world, 1000 people from Apple, and put them together for a week, and it’s not hard to predict that there’s going to be a very large number of great conversations and exchange of ideas. This is where it all happens – it’s the center of the Apple universe. The success of the iPhone and iPad is as much due to third-party developers as it is due to Apple themselves. This is the only time of year where both get together on such a massive scale. And I don’t think I’ve ever seen so much aluminium in one place before.

WWDC - 30 mins before the keynote

The labs were invaluable

By far the best part of the conference was the labs held each day, where you could talk with engineers from various teams about any questions or issues you had about features of iOS that relate to your app. Most of my lab time was spent with the Xcode and WebKit teams. When you find a bug and are trying to track it down, it’s great to be able to get in touch with the person who works on that part of the OS and have them go into the debugger with your program, and say “ok, I think I can see what’s happening here. You can work around it for now by doing X, and I’ll put this in our bug tracking system”.

I also had some questions about a new feature in WebKit that I’m going to be using, and it was incredibly valuable to sit down and get advice on best practice for using it directly from the people who implemented it. You simply can’t get that kind of thing anywhere else.

Pirated copies of UX Write are no longer in the App Store

It took a flight to the US, a meeting with two people from the app store team, and a very unambiguous demonstration of both the original and rip-off versions of UX Write (including the crash in the latter when you change the text colour, the “UX Write has crashed” screen, and the crash log that it sends to my email address) to convince them, but the problem has finally been dealt with. Now the only version of UX Write you can buy on the App Store is the one which is actually going to be updated with a ton of new features over the coming year and beyond.

I’ve also made some suggestions about how these problems could be avoided in the future, using a very straightforward O(n log m) algorithm in which the hash of each of the n files in a new submission is checked against a database of hashes for each of the m files from every version of every app previously submitted. From there, it would be necessary to filter out known common, publicly-available files (such as resource files from SDKs and open source libraries), and then flagging any app with remaining matches for manual inspection. It would likely be necessary to throw a fair bit of hardware at this, but I can’t imagine it being particularly difficult to implement.

I think they get it now, and I’m really hoping to see something along these lines put in place, because I think it’s very important for the credibility of the app store as a reliable and trustworthy marketplace for both app developers and customers.

My laptop died on Thursday morning

Half-way through WWDC, when you’ve spent the past day or two writing prototype code and test cases to discuss with engineers in the labs, is quite possibly the worst imaginable time to lose an SSD. In my particular case it was an OCZ Octane S2 drive that went, and I believe the failure came about due to either a firmware update I had to install on Monday night so I could upgrade to Mountain Lion, or a compatibility issue between Mountain Lion and the drive’s firmware itself. OCZ’s mac support is laughably bad.

I could have gotten a replacement drive installed, but it looked like that was going to take a few days to organise – time that I simply didn’t have. The situation I was in meant I absolutely had to have a working machine to make the most out of my time in the labs, plus some meetings I have lined up with a number of companies next week. So I bit the bullet and decided to just walk a couple of blocks away to the Apple store and buy a new machine.

I’m now the proud owner of a brand-new 2.8 Ghz quad-core retina Macbook Pro with 16Gb of RAM and 3/4 of a terabyte of (Apple-supported) SSD storage. It was a very expensive day to say the least, but my old laptop was about due for an upgrade anyway, and I’m very happy with the performance of the new machine.

WWDC - New Macbook Pro

There were some great networking opportunities

One of the things I want to do with UX Write in the future is to improve integration with other apps – in particular those which provide complimentary functionality, such as diagram editing (OmniGraffle), text manipulation (TextExpander), and online storage & collaboration (Box). It’s kind of difficult getting data between apps on iOS, since unlike on other platforms this requires explicit cooperation between app developers. I’ve already been doing some of this with Box and Texpad, and met with people involved with both OmniGraffle and TextExpander and I hope to get some some integration happening with both of these great apps.

Everyone loved UX Write

I demoed the app to quite a few people, and had some really encouraging responses. Many were previously unaware of the app – building awareness has been perhaps the biggest challenge for me – but once they saw it they thought it was very cool.

UX Write of course isn’t perfect yet (what software is?), and there’s still a lot of work to be done on advanced features like change tracking, EPUB export, page layout, file management etc. So if you’ve had issues with these, I don’t want you to read the above paragraph as me thinking the app is “done” – it’s still very much a work in progress. But things are looking very good, and I’m feeling pretty confident about the future as I continue to work through my roadmap.

Microsoft released Office for the iPhone

This was one of the biggest pieces of news (or perhaps non-news) to hit iOS in a long time. After 5 years of it being possible to create third-party apps for the iPhone, Microsoft finally achieved the goal of bringing Office to the platform. I tried it out, and perhaps the most amazing thing about it is how spectacularly bad it is.

I don’t usually criticise the competition, but I’m going to make a special case here, specifically due to the incredibly high ratio of brand recognition to actual product quality involved. To be clear, this is absolutely nothing like the Office you’re used to on your PC or Mac, and in fact I really consider it misleading to even use the name “Office” for an app like this. The iPhone version of Word has roughly the same level of functionality as what I remember being present in Wordpad back in the Windows 95 days.

Someone I know at Microsoft has told me there’s an iPad version due out around a couple of months from now. I don’t know any more details, but I’d be very surprised if it provided the full functionality that’s available on the version for the Surface.

San Francisco has an awesome music scene

Would a visit to America still qualify as valid if it didn’t include attending at least one or two live blues performances?

I don’t think so.

Cafe R&B

What I hope to get from WWDC

So I’ve just arrived in San Francisco for WWDC. This is my first time here, and in fact my first trip to the US, and I’m really excited about the conference. Primarily I’m here for networking – I see it as a great opportunity to meet with other developers and chat about our experiences and ideas.

Here are the main things I’m hoping to get out of the conference:

  • They keynote, of course! I’ll be very interested to see what’s announced with iOS 7. There’s the much-rumoured new interface design from Jony Ive of course, but I’m also hoping to see some improvements under-the-hood which make it easier for developing content creation apps. My #1 wish in this area would be a user-visible filesystem which allows you to organise documents by project rather than by application. I’m not holding my breath for this, but a man can dream…
  • Learning from other developers about their experiences with marketing apps – what works, and what doesn’t. To be honest, the development part of this project has been the easiest aspect (a huge amount of work, but comparatively easy). The marketing part has been really hard. It’s an unfortunate fact of life that the success of technology products has more to do with marketing than their actual features or quality. I think this is something a lot of us struggle with, but I’m sure there’ll be plenty I can learn from the experiences of others.
  • Finding other developers to collaborate on an open source file synchronization framework. This is one of the most time-consuming parts of developing a content creation app, particularly given that each different service such as Dropbox, Box, Google Drive etc. has a separate API, so you have to implement each individually. I’d like to put together a framework which takes care of all this stuff for you, so you can just plug it into your app and easily sync with all of these services. I’m sure there are many others who have struggled with this, and I think if we work together we can come up with something that benefits app developers, users, and storage services by abstracting away all the boring plumbing stuff.
  • Identifying opportunities to have UX Write tie in with other apps that provide complementary functionality, as I’ve already been doing with Texpad and Box. I’m focusing specifically on word processing with UX Write, but there’s a number of other types of apps (such as drawing programs, mind-mapping tools, and outline editors) that I’d love to make UX Write work with.
  • And finally, the sessions. These are actually last on my list because I’ve already got access to Apple’s excellent documentation and they are also making the videos available for developers who missed the two-minute registration window for the conference. But it will nonetheless be good to hear directly from Apple engineers about advice on making the most of the platform. In particular, I’m keen to get a better understanding of localisation, as one of my main priorities right now is improving support for a wider range of languages in UX Write.

Given the immense concentration of tech companies in the valley (far more than anywhere in Australia), it’s also a good opportunity to meet with other companies working in the area of mobile and online services, and I have several meetings lined up that I’m hopeful could lead to some useful collaborations in the future.

Pirated copies of UX Write on the App Store

Over the last couple of weeks I’ve been dealing with a very frustrating problem. I’ve become aware of three different instances in which unauthorised, repackaged copies of UX Write have been submitted to and approved for sale on the app store, each under a different name. I’ve been going through the standard process to pursue these cases, but decided to post here as well, to clarify that these copies are not legitimate versions. The genuine version of UX Write is available on the app store here.

The unauthorised versions are as follows:

All three are verbatim copies of UX Write version 1.1.4, with only the name and icon changed. The Getting Started guide has been modified to use the name “Document Master”, even in the case of the last two apps. The screenshots on the app store are completely inaccurate and the descriptions highly misleading, in many cases listing features the app does not actually provide.

The only reason I even became aware of these is because the people who did the repackaging made a certain mistake (the details of which I won’t go into) which results in the app crashing under certain circumstances, where the original does not. Since the actual program itself is unmodified, it still uses my email address as the destination for all user-submitted bug reports and feedback. I’ve received emails about these from more than 200 people so far, none of whom initially realised that what they’d purchased was an unauthorised copy.

Piracy is a fact of life in the software industry and ultimately there’s nothing you can do to stop it. It would not surprise me one bit to see copies of UX Write on the Pirate Bay or other sites that have apps for downloading to jailbroken devices. But the app store is different – it’s run by Apple, who review every submission to ensure it complies with their rules, and once approved, they earn a 30% cut of every sale. So while I wouldn’t even bother spending time trying to deal with copies posted on torrent sites or similar, the nature of the app store is such that I think it’s reasonable to expect a higher standard from it.

The last time something like this happened, Apple refused to do anything about it and told me I had to deal with it myself. I made it clear to them that I’m expecting a better answer this time, and the people I spoke to were very understanding and I’m hopeful they will eventually remove the apps. After all, telling developers such as myself to email the people selling pirated copies to ask if they’d please stop doing so is not, in my opinion, a viable solution. There’s nothing to stop the other party from ignoring emails, refusing to take their copies down, or simply doing so but then resubmitting with a new account and a different name.

I don’t directly blame the reviewers for approving these copies in the first place – there are hundreds of thousands of apps out there and it must be huge task to manage it all. But the process is clearly broken, and needs to be fixed. I’m due to attend WWDC in a couple of weeks and hope to have the opportunity there to speak with people from Apple about the issue and how the situation could be improved. I’m far from the only developer affected by this problem – in checking for other copies of UX Write, I’ve found many other instances of apps from other companies being repackaged and approved as well; it’s clearly a widespread problem.