ARKit World Maps – How To Save/Access Using A Custom UTI File Type?

Question

I cannot locate any documentation specifically listing the type of file that ARKit saves its World Map as. As far as I know it is a .arexperience file. Essentially I am trying to modify a document browser to be able to selectively choose which .arexperience file to load.

I have attempted to enable the supported document types, specifically as public.arexperience with the LSHandlerRank as type String and Value as Alternate, as well as a CFBundleTypeRole as Type String and Value as Viewer.

I have also set Supports Document Browser to YES in info.plist Additional document type properties.

9.7.18 EDIT: I am now receiving the following error. Any thoughts on this? I have cleaned the build folder, closed XCode, uninstalled and reinstalled the project, and restarted my computer, but no change.

9.13.18 EDIT: This error is resulting from a fresh install of both XCode 10 Beta (which includes Swift 4.2) and your sample project. Any idea what's going on? Research indicates a SIGABRT error is the result of an unused outlet, but using the assistant editor which let's me view the connections doesn't display a clear problem...

Answer 1

ARWorldMap is not a file format, nor is it even a uniform data format. When ARKit creates a world map, it contains all ARAnchors present in the session, including custom anchor subclasses defined by whatever app is running ARKit. You can see this in Apple's sample code:

• Creating a Persistent AR Experience saves an image snapshot in an anchor to help you reorient yourself for resuming a session from the world map later.
• SwiftShot saves the game board location in an anchor before sending the world map to another player, so that both players know where the board is before starting a game.

And on top of that, ARKit doesn't even save world map files — you're responsible for serializing ARWorldMap instances (and whatever they contain) to binary data and saving it to a file. (Or doing something else with that data, like sending it over a network. Or serializing some object graph containing an ARWorldMap instead of just the map itself. And so on.)

As such, there's no one "ARKit World Map" format — each app that uses ARKit saves its own custom data in a world map, and that data generally isn't meaningful to other apps. (There's SwiftShot maps, ThisApp maps, ThatApp maps, etc.)

---

Now, you could define your own file format — just declare that, when your app is NSKeyedArchiver-ing an ARWorldMap and writing the resulting Data to a file, that's a .myappworldmap file, which has the UTI com.example.myapp, and so on. And you could go on to declare that as a user-visible document type and implement Document Browser support. (As described in excellent detail in @BlackMirrorz's answer.)

But should you?

In practice, ARKit world maps are (mostly) transient data. To be able to relocalize to a previously saved world map, the device loading the map needs to be in very similar real-world environment to the device that saved the map — e.g. in the same room, with the same lighting conditions, with generally the same stuff in the room (yesterday's messy desk isn't always messy in the same way as today's), etc. The older a wold map gets, the more likely the real-world environment it describes is no longer sufficiently similar.

You can use ARWorldMap for limited forms of persistence, but it's not really meaningful to treat them as user documents in the sense of, say, a Word/Pages doc or a photo — if you copy them between devices, or to other people elsewhere in the world, there's not much usefulness to them on the receiving end.

For many apps, the only meaningful way to recover sessions from world maps is to save only one map — the last environment the app was used in — and attempt to resume from that map on launch. (Failing that, assume the user is in a different environment and start over.)

If it is meaningful for your app to remember multiple past environments — say, an interior-design app that places virtual furniture and might be able to remember different rooms of a home — it's probably more helpful to your user to make the UI for choosing saved maps more integrated with the experience of your app, rather than kicking them out to a generic document browser.