Post not yet marked as solved
I have the same problem, runnig Catalina beta 1 and 2. Beta 3 tries to do a fresh install and shows an error at end. I am using a Mac Mini 10.15 Beta (19A501i) (Built Late 2012).I tried the Beta 3 install many times. The errors is shown when I start the Mac after the Installation.Today, I tried it again. This time the update went through. I am now on Build number 19A512f
Post not yet marked as solved
Apple watch 4 (5.2.1)WatchOS Beta 3 Update resolved this issue.
For the benefit of anybody with a similar problem the solution was to set the bundle IDs and provisioning profile specifier via individual variables.So in the xcode project in each target I use these variables in place of the values then I set them on the command line when I do the build.$APP_BUNDLE_IDENTIFIER$APP_PROVISIONING_PROFILE_SPECIFIER$EXT_BUNDLE_IDENTIFIER$EXT_PROVISIONING_PROFILE_SPECIFIERxcodebuild -verbose clean archive -project projects/IOSExtDummy/IOSExtDummy.xcodeproj -scheme IOSExtDummy -configuration Release -archivePath bin/plugins.xcarchive HEADERMAP_INCLUDES_PROJECT_HEADERS=NO USE_HEADERMAP=NO APP_PROVISIONING_PROFILE_SPECIFIER=FooBar_dev EXT_PROVISIONING_PROFILE_SPECIFIER=FooBar_ext_dev CODE_SIGN_IDENTITY="iPhone Developer" CODE_SIGN_STYLE=Manual DEVELOPMENT_TEAM=W4Zxxxxx APP_BUNDLE_IDENTIFIER=com.foo.bar EXT_BUNDLE_IDENTIFIER=com.foo.bar.myExtI wish there was some documentation on doing command line builds of apps with extensions.
Post not yet marked as solved
I think maybe this thread is digressing.We already have a desktop version of the app that does all of this, i.e. stores documents in the Documents directory and detects when a change has occurred and then processes it.Up until now our IOS version did not need to support this because the documents could only be accessed via the app itself which simplified things.The reason for this thread was to find out if IOS provided any way to monitor what other apps were doing in our documents folder, assuming we supported UISupportsDocumentBrowser. I think the answer to this is 'No' unless we want to use kqueue and have a file handle open to every file and directory in my Documents directory which in our case is not piratical.So if we want to use UISupportsDocumentBrowser we will need to do the same file scanning we currently do for the desktop version.Thanks for your help on this.
Post not yet marked as solved
Currently we do not expose the files in the Documents directory. The user has to select the file in our app and do an "Open In" to pass it to MS Word. After the user has editied the file they can pass it back using "Open In" again. It works but it isn't the way users are use to working with documents.But with IOS 11 I would like to make use of the ability to share the Documents directory with other apps to make this work flow more natural.
Post not yet marked as solved
About the app:It is a sync&share app that provides end to end encryption. It is a cloud based app but it doesn't fit the pattern of other cloud based apps because everything including the metadata is encrypted. This means I cannot fetch a content list from the serve, instead considerable processing needs to be done on the client side to decrypt the data and make it available to the user and then encrypt any changes the user may make and send them to the server. While doing all of this it is also updating its local metadata with any changes made by the remote clients.Our customers are very concerned about security and so enabling iTunes file sharing is not something they want. If we provided support for document browsing I would still need some way to allow them to limit what was browsable.The way I would envision this working, for example, is that the user edits a file in our documents folder using MS Word and save the changes. At this point the file has changed but it cannot be synced until the app is brought into the foreground. Once the app is active it recognizes that something has changed in its documents folder and syncs the changes with its central server. This isn't ideal but since the app is not allowed to run in the background for any length of time there is no way around it. What we need is a new 'service' class of apps that are allowed to execute continuously in the background but I do not see that coming any time soon. So the user needs to be aware that the file will not by synced until the app is moved to the foreground.Re: kqueue:In order to detect changes to a file you need to have a file handle open on the file itself. Monitoring folder with kqueue will only report files/folders being added/deleted in the monitored folder.We do testing where the app is managing 100,000 + files so we need to be able to handle this case.
Post not yet marked as solved
Thanks for the detailed answer.As for documents changing when the app is in the foreground, is there anything other than access via ITunes that can do this? ITunes can only access what is in the root of the Documents folder, it cannot descend into sub folders as far as I know so it is limited in what it can do. This is not actually relevant to my app though since I do not plan on making the folder available via iTune's file sharing.Using kqueue only works to detect changes made while the app is running so I will still need to do a scan when the app starts anyway. it would also require opening a file descriptor for every file which is not practical when you are dealing with 100,000 + files.I had been hoping there was some magic way of doing this. 🙂
Post not yet marked as solved
So there is no way that the app itself can provide the user with a switch to enable/disable the feature?Similarly for iTunes file sharing, it would be nice if the user could enable/disable the feature for possible security reasons.
Post not yet marked as solved
You may have already found this but your answer is probably here: https://stackoverflow.com/questions/32525448/ios-share-extension-not-getting-the-imageYou are probably calling[self.extensionContext completeRequestReturningItems:@[] completionHandler:nil];before you should.I had a similar problem, I got away with it until IOS 11.
Post not yet marked as solved
As a test I did that and just played a silent music file while in the background to keep the app alive. It works great and allows me to do eerything I need but Apple explicitly states that apps that use features such as that for purposes that they were not intended will not be allowed in the store.Maybe I can convince them to make an exception.
Post not yet marked as solved
That would allow the upload to be performed in the background but it doesn't get you all the way there because the data encryption and other processing can take a long time also and there is no guarantee it can be done in the grace period granted apps to run in the background before being suspended.The example I gave with the problem of processing and uploading large files is just one example of the problem of not being able to run n the background, there are others that do not involve uploading large files. The main problem is that the app is really intended to be run as server that provides secure access to a cloud based file system. It works great on other platforms it is just on IOS where it has problems because of the inability to run in the background.
