dsym file

I think the standard approach is a custom URL scheme if your data is short enough to fit in a URL (not sure what limits, if any, there are on the length). There's also the keychain with the same sort of limit - it's meant for small bits of info like passwords.I believe as of iOS 8 you can now have a shared app container so apps from the same developer can share data. One app could write a file and the other app could read it. That, in combination with the URL scheme, may be a more flexible approach.

It would be easier if you can convert the .tex file to a PDF.

I think that the openParentApplication() is the fallback you would use on Watchkit 1.0 / iOS 8.x deployments. For the Watchkit 2.0 / iOS 9.x deployments, the WatchConnectivity framework is the way to go. I'm not sure how to implement the if #available() tests though, since it appears that Watchkit 1.0 SDK is missing from Xcode 7 currently. Additionally, we'd probably have to assume that the user will be forced to upgrade both iOS (to 9.x) and Watch OS (to 2.x) simultaneously when the production versions are rolled out, so we can use some variant of if #available(iOS 9.0, Watchkit 2.0, *) for our tests.Any thoughts on writing Watchkit 2.0 apps that also run on WK 1.0? Or just assume we push a new version, and keep a couple of branches (yuck!)?[edit] It appears that you can add a WatchKit 1.0 target to the project, and then share some files between the two variants. Now, I still need to find out how to get WatchKit 1.0 sdk into Xcode 7...

App Store apps need to be sandboxed.Files or folders explicitly selected by the user will get added to the current sandbox, this requires the user to use either the Open Dialog or do a Drag & Drop of a file system item onto the app.Use security scooped bookmarks if you need to be able to access the file/folder after the app is quit and restarted.

If you select the file and open the Assistant Editor pane on the right side of the main Xcode project window (using the button in the toolbar or the menu View>AssistantEditor>ShowAssistantEditor), one of the sections in the File Inspector has checkboxes which let you manually set which Targets the files should be added to.Sorry, but I don't know why you're not getting the option when you create the files.

I'm seeing the same thing, but the more I struggle, the more I think this is expected. If you notice, when you add a new target, there's a new Watch Framework target. If I add a new Watch framework, I have no problem doing an @import of it. Think about the current frameworks. The framework code lives on your phone. The reason shared frameworks worked before was because the Watch extension and iPhone app both were on your phone. Now, the code for the Watch extension and the iPhone app are on separate devices. While the code might be the same, the code is hosted on physically separate devices. An official comment from Apple would be good, but after messing with search paths for a while and then thinking about the situation, I think it's accurate to say that your shared code is going to need to be duplicated. In my case, this is several constants and networking code.It would be great if Xcode could do this duplication for us, in some sort of omni-framework that automatically gets installed on both devices. After

What does localizedDescription of the error objet contains? Usually this is something presentable to the user. If it doesn't makes sense or isn't localized I suggest filing a bug report.Dirk