User Profile

With the latest XCode release I do reglarly get the following error message when I try to run/debug an App in the simulator:The request to open "the.bundle.identifier" failed.The request was denied by service delegate (SBMainWorkspace) for reason: Unspecified.Just trying again will usually work, though sometimes I do get the error again, so I have to try to launch the App several times before it actually works. This is totally unpredictable. Often I can run the App in the simulator without any problem, but overall I do still get this error far too often to ignore it.So what does this error mean? "unspecified" is not a very specific message. And how can I fix this?This issue seems to be related to the simulator only. It never happens when debugging on a real device.

Some time ago I was getting email notifications when ever an App status has changed ("waiting for review", "in review", "processing for the AppStore" and "Ready for sale"). But now the last one I get is the notification that the App is going into review. I no longer get any notifications that the App was approved and is available in the AppStore. So I have to constantly check in iTunesConnect if and when the review is finished and the App is available in the AppStore.Is this normal now, or is there something broken in my iTunesConnect account? I'd like to know when the Review is finished, so I can update the Apps webpage to promote the new release etc. And because the review can take days or sometimes even weeks, not getting email notifications is a big pain.

I have a strange issue with Notarization or Gatekeeper under macOS 10.15.6. After signing and exporting my App from the Xcode Organizer, I'm using atool to notarize my App (*). This works fine and when everything is finished, I also check with… spctl -a -vv App I get the status… App: accepted source=Notarized Developer ID origin=Developer ID Application: xxxx So everything is fine. I create a ZIP archive with the App and some read.me files and put it on my web page so users can download the App. So now the weird which I don't understand: If I download the ZIP archive with Safari, extract the archive, I can launch the App and get a notification from gatekeeper that the App was downloaded from the internet, it was checked for malware, none were found and I can launch the App and cancel. The App works fine from now on (why do I get this warning in the first place? Shouldn't the Notarization and signing of the App prevent these kinds of warnings?) For the App from the ZIP spclt reports: App: accepted source=Notarized Developer ID origin=Developer ID Application: xxxx If I download the archive with the old version of my App using its "search for Update" feature (the App was originally developed and notarised under macOS 10.14, written in Objective C), and extract the ZIP archive and launch the App, it launches without any Gatekeeper warning (which is what I would have expected). For the App from the ZIP spclt reports: App: accepted source=Notarized Developer ID origin=Developer ID Application: xxxx If I launch the App with the new(!) version of my App (a complete rewrite in Swift, so this is a new Code project, but with the same bundle ID as the old App), extract the Archive and try to launch the downloaded App, the finder gives me an Error message "The App 'App' can not be opened" (no further description). Launching the App fails!!! For the App from the ZIP spclt reports: App.app: File created by an AppSandbox, exec/open not allowed So somehow the Finder seems to treat the ZIP file different, depending of the App which has downloaded the file. This makes no real sense to me. The App is signed and notarized correctly, shouldn't this be enough to let the Finder check that the App is not modified and can be launched without error or warning? So my question is, why does it behave in three different ways with exactly the same ZIP archive, depending of the App which has downloaded the ZIP archive. And the most important question is: What do I need to do so that my new version of may App can download the ZIP archive (for the search for Updates" feature) so that when extracting the ZIP the App can be opened successfully without error? Notes: (*) Xcode is unable to notarize my App. It always fails with the error, that I had to accept certain contracts first. This seems to be an old of Xcode. This issue seems to occur when a developer is a member of other developer teams. Xcode seems to check the wrong contracts (from the other teams), not your own. Fortunately "atool" works.

In order to save a photo in the album you can use different APIs: ) You can use the simple UIImageWriteToSavedPhotosAlbum() call, which takes an UIImage object as parameter. The problem here is that because the image must be an UIImage, you can no longer save the original(!) photo data. The file format, animations for GIFs and all metadata will be lost. ) You can use the "PHPhotoLibrary" framework, which can save the original photo data, including animations, metadata etc. So this would be the best option. The big problem is with the access privileges: I do only want to save photos in the album, not read them. So theoretically I would only need the key "NSPhotoLibraryAddUsageDescription" in the Info.plist. But this only works for the first approach (UIImageWriteToSavedPhotosAlbum). The seconds approach does not work with "NSPhotoLibraryAddUsageDescription", it will just crash and the Xcode console states that the key "NSPhotoLibraryUsageDescription" is required, so this requests not only write access but also read access. For getting a new iOS 14 entitlement for my App, I am no longer allowed to have the "NSPhotoLibraryUsageDescription" key in the Info.plist, which makes it impossible to save the original photo data in the album (because PHPhotoLibrary requires the key NSPhotoLibraryUsageDescription). Is the another way to save the original image data in the album? Like an animated GIF, or photos with meta data? Note, I can only have the key "NSPhotoLibraryAddUsageDescription" in the Info.plist?

UIWebView is deprecated and Apple urges us to switch to WKWebView. Unfortuately WKWebView seems to be still lacking far too many features to be a valid replacement of UIWebView. Therefore I would likt to know if there are ideas how to achieve the following tasks...Proxy SupportWhen using UIWebView we could easily route all network through an App-specific proxy. All you need to do is to implement NSURLProtocol for "https" and "https" requests and handle the proxy there. WKWebView does not support NSURLProtocol and does not have any seting for a proxy. Configuring the proxy at system level is not an option, because there's only a proxy setting for WLAN available here, not for mobile internet (G3/G4/LTE), and the systems setting is applied to all other Apps as well. So all Apps which require their own Proxy can not use WKWebView right now (for example kid-safe browsers which need to filter the web). Caching, Offline UsageWhen using UIWebView and NSURLProtocol it's possible to control all network requests for the main web site and all its resources (images, JS, CSS etc). This is great for implementing a special caching for a real offline mode, so the App remains usable even if there's no internet connection. WKWebView doesn't support this. Cookie PolicyWKWebView doesn't allow to configure the cookie accept policy.

In one of my Apps I'm using AVSpeechSynthesizer let the watch speak text to the user, which works great in general, but not when selecting a German voice (the only one that is available under watchOS 6,1,1 is "Anna-compact"). With the German voice to sperak German text, that App always crashes under watchOS 6.1.1 (it did not crash under watchOS 5, and I think not under early watchOS 6 releases, though I can't really tell when this issue started).The code which starts the speech output is simple: AVSpeechUtterance *utterance = [AVSpeechUtterance speechUtteranceWithString:text]; utterance.voice = [AVSpeechSynthesisVoice voiceWithLanguage:@"de"]; [self.speechSynthesizer speakUtterance:utterance];The crash happens within the speakUtterance call, the App never returns from this call, also none of the delegeta methods of AVSpeechSynthesizer is ever called here, so the crash occurs while the watchOS initializes its internal data structures.The watchOS throws this exception:EXC_RESOURCE RESOURCE_TYPE_MEMORY (limit=80 MB, unused=0x0)and is crashing here (deep within the TTS component of watchOS):#00x1c4f370c in __CFToUTF8 ()#10x1c586f48 in __CFStringEncodeByteStream ()#20x1ceee8a4 in -[NSString(NSStringOtherEncodings) getBytes:maxLength:usedLength:encoding:options:range:remainingRange:] ()#30x1cffdecc in _NS_os_log_callback ()#40x1c1e538c in _os_log_fmt_flatten_NSCF ()#50x1c1e4c10 in _os_log_fmt_flatten_object ()#60x1c1f1308 in _os_log_impl_flatten_and_send ()#70x1c1f0bec in _os_log ()#80x1c1f6b90 in _os_log_debug_impl ()#90x3fbb466c in -[TTSRegexHelper _addRules:] ()#100x1bf945a8 in _dispatch_client_callout ()#110x1bfa0eb8 in _dispatch_lane_barrier_sync_invoke_and_complete ()#120x3fbb4368 in -[TTSRegexHelper addRules:] ()#130x04ecb050 in ___lldb_unnamed_symbol8$$TTSSpeechBundle ()#140x3fbc79ac in -[TTSVocalizer loadResource:mimeType:resourceURL:supportsAccurateWordCallbacks:] ()#150x3fbc4d4c in -[TTSSpeechServerInstance _loadVoiceResource:voiceResource:] ()#160x3fbc4960 in -[TTSSpeechServerInstance _initializeSpeechEngine:] ()#170x3fbc4b7c in -[TTSSpeechServerInstance _initializeSpeech:] ()#180x3fbc260c in -[TTSSpeechServerInstance _processCurrentRequest:] ()#190x3fbc3704 in -[TTSSpeechServerInstance _handleSpeechThread] ()#200x3fbc25c0 in _SpeechThread ()#210x1c1cc930 in _pthread_start ()I've no idea if this is a general issue/bug of watchOS 6.1.1 (it comes with damaged/broken voice files for German), or if only something on my watch got damaged for some unknown reason.Has anyone any experience in using AVSpeechSynthesizer on the AppleWatch and can reproduce this crash when using the German voice? Does it work under watchOS 6.1.1 on other devices?The text itself which should be read can not be the problem, because it crashes even with the text "1 2 3" (counting to 3), so no special characters (umlaut) or other fancy things involved. As test case "1 2 3" works great because this same text can be used for all languages and voices in the same way.

I'm facing a few problems with UISearchController under iOS 13.I'm using a UISearchController within a UITableViewController in order to search for something within the table.The first problem occurs if the TableView only has a few items, so that there's a lot of unused room at the bottom of the TableView. When the UITableViewController is shown, the search field is hidden, just as it is supposed to. But once I start scrolling to make the search field visible, it is absoultley impossibel to scroll back in order to hide the search field again. This only works if there are more cells in the table that will fit on screen. This doesn't look very nice. This issue occurs on both iPad and iPhone.Is there a way to hide the search field by scrolling again, just like it is supposed to work and like it is working when enough cells are available?The second problem is a big one and occurs if I set a darker barTintColor for the navigation toolbar (and a bright or white tint color to the navigation toolbar buttons and texts). Whenever I scroll down to reveal the search field, the whole navigation toolbar (including the area with the search field) will change its color and will get the color of the background color of the TableView (usually white or light gray for the "grouped" tables). This makes the search field, the icons and title of the navigation toolbar totally unreadable, because they still have the same bright/white color as before.I thought that this might be intended behavior when the searchBar.searchBarStyle property is set to .minimal, but this doesnät seem to be the case, because it also happens when using .prominent.This issue only occurs on the iPad, but not on the iPhoneIs there a way to make sure that the navigation toolbar does not change its color when scrolling the search field into view? With using the default colors (white navigation bar) this is not a big deal and hardly noticable, but with other colors this can get ugly.BTW: the issue with the colors does not happen in the simulator, only on a real device. But this might be because of the iOS release: the simulator only supports iOS 13.0, while the real device uses iOS 13.1.3. Sothis might be one of the many new bugs of iOS 13This is how I create the UISearchController:override func viewDidLoad() { super.viewDidLoad() searchController = UISearchController(searchResultsController: nil) searchController?.hidesNavigationBarDuringPresentation = false searchController?.dimsBackgroundDuringPresentation = false searchController?.obscuresBackgroundDuringPresentation = false searchController?.searchResultsUpdater = self searchController?.searchBar.searchBarStyle = .prominent navigationItem.searchController = searchController navigationItem.hidesSearchBarWhenScrolling = trueBoth of the above issues do look extremly ugly, so my current "workaround" is to always show the search field (using navigationItem.hidesSearchBarWhenScrolling = false). This is not really what I want, but at least it doesn't look as ugly.

I've noticed that since iOS 11, when setting the headingOrientation property of the Location Manager to CLDeviceOrientationPortraitUpsideDown the location manager returns wrong heading values. When the device is facing north the location manager returns south as the heading in this case. Up to and including iOS 10, this works correct and as expected. Since iOS 11 I do get wrong values. A workaround would be to set the value for headingOrientation to CLDeviceOrientationPortrait when the device is in upside-down orientation, but of course only under iOS 11. iOS 12 seems to have the same issue.Is this is new policy of the iOS, which I have missed, or is this a bug?

In my App I'm using the NSFileCoordinator to read and write files to the iCloud, so they sync between devices. This works fine in general. But under iOS 11 I've noticed on my iPad (but not on my iPhone), that some times the iCloud syncing stops competely. If this happens this issue won't go away until the device is rebooted. Then evertyhing works again for some time. Some time later (days, weeks) the problem is back, iCloud sync fails completely."So I used the debugger to find out what's going on. And I noticed, when the problem occurs, all attepmts to use the NSFiIeCoordinator will lock up. For example whan calling the method "coordinateReadingItemAtURL:options:error:byAccessor:" the block which is called when it is safe to do the read operation is never called. The same happens for coordinated write operations. Every call to the coordinated file operations will block forever. Even if there's only one single call, so there can not be a dead-lock within the App. Is this a known issue (the fact that this issue vanished after a reboot and does not occur on my iPhone indicates that is might be (one of the many) bugs of iOS 11)?Is there anythign special I can do to avoid this problem?

One of my devices is already running iOS 11.2 Beta, therefore I've also installed the XCode 9.2 Beta, which is required for devices with iOS 11.2. But it seems that XCode 9.2 is no longer able to run/debug Apps on my iPad Air 2 with iOS 11.1 (the latest public iOS release). It does still work with devices running iOS 10, 9 or 8.For my iPad Air 2 I get the following error in the "Devices & Simulator" window of XCode:Could not locate device support files. This iPad Air 2 (Model A1567) is running iOS 11.1 (15B93), which may not be supported by this version of Xcode.In the past I had never any issue when running/debugging Apps on devices with older iOS releases. Is there a way to make XCode 9.2 Beta to work with iOS 11.1 as well? How?

I do have an issue with XCode 9 Beta 6. In all of my iOS projects, it shows some red warnings in the "Capabilities" view.- In the "App groups" section, it shows a red exclamation signe with the message "Add App groups to your App ID". But the App ID has "App groups" enabled and configured in the developer portal correctly, and the group is also listed correctly in the "Capabilities" view. So what's this message about?BTW: XCode 8 does not show this warning.- The iCloud section shows a warning "Add iCloud Containers" to your AppID. But there is already the correct container assigned to the App ID, and ithis one is also shown correctly in the list of containers within the "Capabilities" view.And again, this is not an issue in Xcode 8.And despite these read warnings in XCode, the features which rely on iCloud and the App groups do work as expected when using XCode 9 Beta 6 to built the Apps.Is this is known bug of XCode 9 Beta 6, or do I miss something new which I need to take care of for iOS 11?

Under iOS 11 it seems that UIBarButtonItems of type UIBarButtonSystemItemFlexibleSpace have no effect anymore in a navigation bar. I've used them to get more space between certain groups of icons on devices with larger screens. This works fine under iOS 10 and older, but under iOS 11 all icons are "squeezed" together on one side. So adding UIBarButtonItems of type UIBarButtonSystemItemFlexibleSpace looks like there were no such buttons added at all.What exactly must be done under iOS 11 to distribute the available space between the icon groups?

In my App I have a DocumentPicker extension (works in iOS 8 up to iOS 10) which uses the UIDocumentPickerExtensionViewController only (no FileProvider necessary). This works great under iOS 8, 9 and 10, but under iOS 11 I can see the extension in the Files App, but its not working.So I implemented a FileProvider extension for iOS 11 and it seems to work fine. In the Files App I can see my files, preview them, delete them etc. I can even copy a file to iCloud Drive. So it looks like everything is working fine. My App does not use the cloud, all files are stored locally, so there's no issue at all with network errors or any delays.But when I open Safari, go to a web site with an upload form and try to pick a file for the upload, I do get the same file browser that is used in the Files App, and I can also browser my files which are provided by my FileProvider extension, but if I pick a file, the File browser is dismissed, but no file is passed to the upload form. If I do the same with a file from iCloud Drive, this does work.So do I miss something here? Or is this not yet working in the current iOS 11 Beta?The fact that the Files App is able to get the file from my extension to copy it to iCloud Drive indicates, that my extension seems to be working correctly. But then why does Safari fail to get the file from the extension? Or is the "iCloud Drive" Option not using the public API for the FileExtension and therefore it works?Unfortuntely this is a completely new API and no other Apps are available from the AppStore to test this. The only options are to test with the Default options that are built-in into the iOS Beta, and this gives mixed results. So it's difficult to find out where the issue is.Does anyone else tested their FileProvider extension with the "upload" feature in Safari? Does it work or does it fail as well?Any ideas what could be wrong?