Bug Reports – Cocoanetics https://www.cocoanetics.com Our DNA is written in Swift Fri, 10 Dec 2021 11:14:07 +0000 en-US hourly 1 https://wordpress.org/?v=6.4.3 39982308 Bug: Progress with Child https://www.cocoanetics.com/2021/12/bug-progress-with-child/ https://www.cocoanetics.com/2021/12/bug-progress-with-child/#comments Fri, 10 Dec 2021 11:14:06 +0000 https://www.cocoanetics.com/?p=10732 There is a parent progress that has a total unit count of 1000 units. A child progress was added with pending unit count 1000. When the child progress’ completed unit count is updated, then the fraction completed of the parent is updated, but the completed unit count is not.

Submitted as Apple Feedback FB9803982. The beautiful sample app can also be found on my RadarSamples repo.

Steps to Reproduce

  1. run the attached Sample App on iPhone Simulator
  2. Drag the slider slowly to the right. Notice that only the parent’s fraction completed changes.
  3. Continue dragging the slider to the right maximum. Notice that when you come to the right side of the slider the parent’s completed count is updated.
  4. Drag the slider a bit to the left. Again, only the parent’s fraction is updated.
  5. Drag the slider to the right maximum. The parent’s completed unit count is now double what it should be. In fact every time the child completes, 1000 is added to the parent’s completed unit count.

Expected Behavior

When adding a child progress with a pendingUnitCount value greater than 1, then the completedUnitCount should also be updated in tandem with the fractionCompleted value.

Actual Behavior

Only the fraction completed of the parent is updated. When the child reaches 100%, the pending value is added to the completed unit count. If the progress reverses for some reason, the completed unit count remains and when the child gets back to 100% the pending value is AGAIN added.

]]>
https://www.cocoanetics.com/2021/12/bug-progress-with-child/feed/ 17 10732
Bug: “Testfield in Row of List with Movable Items” https://www.cocoanetics.com/2021/10/bug-testfield-in-row-of-list-with-movable-items/ https://www.cocoanetics.com/2021/10/bug-testfield-in-row-of-list-with-movable-items/#comments Wed, 20 Oct 2021 15:11:35 +0000 https://www.cocoanetics.com/?p=10729 I was trying to recreate an existing user interface view in SwiftUI but got stumped for a while by some erratic behavior. I’ve built a nice sample app which is also on GitHub. This has been filed as FB9715757.

Description

If you have a List with movable rows that has a Textfield in its rows there is an issue if you try to move a row while it is first responder.

Steps to Reproduce

Please run the provided sample app on iOS 15 simulator.

  1. Tap on the item titled ‘One’ below and modify the string.
  2. Use the item’s reorder handle to move it into second position.
  3. Drag it back up into first position.

Expected Behavior

That you can move the row back into first position.

Actual Behavior

The system won’t let you drop the row in first position. Sometimes the row disappears entirely leaving a gap between the “Two” and “Three” items (see screenshot)

A functioning workaround is if the first responder is resigned before the move itself.

]]>
https://www.cocoanetics.com/2021/10/bug-testfield-in-row-of-list-with-movable-items/feed/ 14 10729
SwiftUI: Laziness of List Interferes with Selection and Presentation of Detail https://www.cocoanetics.com/2020/08/swiftui-laziness-of-list-interferes-with-selection-and-presentation-of-detail/ https://www.cocoanetics.com/2020/08/swiftui-laziness-of-list-interferes-with-selection-and-presentation-of-detail/#comments Mon, 24 Aug 2020 14:47:48 +0000 https://www.cocoanetics.com/?p=10628 iOS 14 introduces some laziness in certain views, like for example there are now lazy variants of HStack and VStack. I’ve been working on a SwiftUI-version of an app of mine and the findings of my research for these bugs led me to believe that Apple added some lazy optimisations to Lists as well.

Unfortunately those optimisations seem to be breaking selection and presentation of detail views to a degree that they would be show stoppers for any universal app relying on List and its automatic promotion to being a split view on iPad.

I filed this as FB8521674 in the Apple Feedback App.

]]>
https://www.cocoanetics.com/2020/08/swiftui-laziness-of-list-interferes-with-selection-and-presentation-of-detail/feed/ 10 10628
Old and New https://www.cocoanetics.com/2019/10/old-and-new/ https://www.cocoanetics.com/2019/10/old-and-new/#respond Thu, 03 Oct 2019 09:16:30 +0000 https://www.cocoanetics.com/?p=10623 I know, I know, I cannot seem to find any time to reasonably blog about my life as developer. Nevertheless here are a few tidbits of late.

Mac Mini Time Machine replaces Time Capsule

For a long time I had an older generation Apple Time Capsule (1TB) for my backups, but it became more or less useless to me when a full backup of just one of my machines takes 75% of the capacity. A year ago, I had migrated all my WiFi to a Ubiquity setup with 3 Hotspots positioned throughout the house and one on the roof for some outdoor coverage. That had made the WiFi coming out of Time Capsule obsolete.

Then I bought a new Mac Mini (2018) which Apple finally refreshed after a very long time. I kept the Time Capsule and used a USB-connected 4 TB external HDD as backup destination. But that didn’t work so well, that I didn’t even enable backups when I moved to a newer iMac and my girlfriend got my previous one.

So yesterday, I finally decided to remove the Time Capsule from my network and instead plug the external HDD into the Mac Mini. Naturally, the USB 3 is much faster than USB 1 on the Time Capsule. And of course having Gigabit-Ethernet connecting them, increases throughput by another order of magnitude.

In order to see the backup drive on other machines you need to share the volume/folder as a time machine destination.

Share as a Time Machine backup destination

I kept getting an error about permissions, even though I had given the user read and write permissions in the sharing dialog. But then I remembered, since this was a previously used drive, I also needed to adjust the file system permissions. The administrators’ group also needed to be able to read/write.

Fix File Permissions

I had disabled my iMac’s wired ethernet connection to test something and because of this the first backup was still going on the next morning. But as soon as I re-enabled the cable connection, the backup speed increased dramatically. Which makes sense, the WiFi Connection is reported as 54 Mbit/s, whereas the Ethernet can do 1 Gbit/s – a factor of 18x faster.

That is, theoretic maximum throughput. So what was the actual transfer speed?

With the free Blackmagic Disk Speed Test I measured the writing from MacMini to the external HDD at 75 MB/s, that would be 600 Mbit/s. When I ran the same speed test from my iMac via network, I got a writing speed of around 100 MB/s, which is very odd: why would it write faster oder the network than when directly connected?!

I didn’t test the speed of the USB connection of the Time Capsule, but I found that somebody had gotten 44 MB/s for the internal drive and and 11 MB/s for an external USB drive. Connecting the external USB 3 HDD to the Mac mini as opposed to the Time Capsule increased my backup speed about 7x. No wonder that backups would be so painfully slow with this USB bottleneck.

Those old Radars

After many years of campaigning against the infamous Radar Web, Apple introduced Feedback Assistant for Developers (in June 2019) a new web app and also native Mac app. This app apparently is now preinstalled in macOS 10.14 or higher.

It basically works somewhat similar to the previous Radar web app, but feels fresher and more friendly. During the beta phase of iOS 13 I filed a few bug reports and was pleased to see that there seems to be much more responsiveness in the new system. It feels more like a dialog with Apple now, as opposed to the prior Radar black hole. One – probably automated – kind of response would be to check the problem again with a newly released updated version of Xcode.

Mixed into your inbox you’ll also find a couple of Announcements pertaining to release notes or a new beta program. Then there’s a Sent Folder which contains copies of all Radars I filed for the past 11 years.

Bildschirmfoto 2019 10 03 um 09 07 49

For a while it was not possible to download attachments we had uploaded. So if I had meticulously crafted an app to reproduce an issue, I had no way to download it. Apple fixed that at the end of August 2019 for the web version. I’m still unable to download anything via the Mac app.

But the thing that delighted me yesterday was receiving this – again automated – response to one of my oldest open Radars, one from July 2012. The original Radar had been closed as duplicate of another one, but the copy of it in Feedback Assistant was still showing as open. As are most other imported bug reports. I have a response that it has been closed as duplicate, but the status is still Open. Possibly we’ll see Apple close these bit by bit the same way.

Closing Old Radars

At first I thought that this might be a new text snipped, but then I looked back and found the earliest copy of this text in a response from Apple, dated May 5, 2015.

Thank you for filing this bug report.

This is an older report and much has changed since it was filed. We are closing it. If this is still an issue for you, or if you have questions regarding the resolution of this issue, please update your bug report with them.

Please be sure to regularly check new Apple releases for any updates that might affect this issue. Again, thank you for taking the time to submit bugs. We sincerely appreciate your input.

I hope that Apple will now take a more active role in communicating with developers about issues in their software. Apple could have started with a fresh slate, but they chose to import more than a decade worth of old Radars. Now they have to start closing those Feedbacks, or how are we now colloquially referring to those issues we raise?

Always-On Apple Watch

The third new thing is that for a while I had been tracking my sleep with Sleep++ to see how accurate this is. For this purpose I had a series 3 ceramic Watch that I would wear at night and then during the day I would switch to my series 4. The one major announcement which made me jump up to find my wallet, was the announcement of the Always-On functionality on series 5.

It came as quite a surprise to me, because I had resigned to the situation that we would never have the battery capacity in those small devices to power a screen for an entire day. Being able to adjust the refresh rate of the display – amongst other tricks – allows the watch to finally do what a watch should do: to tell time!

Always-On

The first versions of watchOS 6 and iOS 13 had some issues where the battery would drain too quickly. But I am happy to report that battery endurance seems normal now, at least for my current rhythm alternating watches between day and night. 3 hours sitting at the iMac, typing, and I am at 93%.

A built-in compass (series 5 only) and the noise meter are two additional new features that managed to delight me. It is really true that being able to glance at your watch without having to move your wrist gives the watch an entirely different feel.

]]>
https://www.cocoanetics.com/2019/10/old-and-new/feed/ 0 10623
Regression: CGImageSource doesn’t render background image of certain PDFs https://www.cocoanetics.com/2018/10/regression-cgimagesource-doesnt-render-background-image-of-certain-pdfs/ https://www.cocoanetics.com/2018/10/regression-cgimagesource-doesnt-render-background-image-of-certain-pdfs/#respond Wed, 17 Oct 2018 15:22:25 +0000 https://www.cocoanetics.com/?p=10586 This is a curious bug in Mohave, which is causing some headache for a client of ours who is relying on this functionality in their production work flow, but since this is broken in Mohave they cannot use machines they have already upgraded for this.

And before you ask why we didn’t report this earlier, as there were several months between WWDC and now… well, we didn’t use Mohave in production and it didn’t occur to us that something that was working before could be broken in a nice and shine new macOS version… 🙂

Filed in OpenRadar and under rdar://45338633. Due to the proprietary nature of the sample PDF, I didn’t post that to my Radar samples repo.

Summary

CGImageSource as of Mohave is no longer able to render the background images for certain PDFs coming out of Adobe InDesign CC2018. This is a regression because on earlier macOS versions this worked fine.

Steps to Reproduce

Build&run the provided sample app on Mohave

Expected Results

  • you should see the background image with the woman

Actual Results

  • you only see some text and boxes in the foreground, the background where the image with the woman should be, is left blank
    On the console you see the output:

    [Cocoanetics.CGImageSourcePDFBug] img_alphamerge_stage: Assertion failed - 
         unknown source alpha

Here’s the code I am using to generate thumbnails

import Cocoa

class ViewController: NSViewController {

    @IBOutlet weak var imageView: NSImageView!
    
    override func viewDidLoad() {
        super.viewDidLoad()

        // Do any additional setup after loading the view.
        
        // You can look at Sample1.pdf and Sample2.pdf
        
        let url = Bundle.main.url(forResource: "Sample1", withExtension: "pdf")!
        let data = try! Data(contentsOf: url)
        let source = CGImageSourceCreateWithData(data as CFData, nil)!
        
        let thumbnail = thumbnailImageFromImageSource(source)
        imageView.image = thumbnail
    }
}


// MARK: - Helper Functions

func thumbnailImageFromImageSource(_ imageSource: CGImageSource, 
                                   subAssetIndex: Int? = nil) -> NSImage?
{
    let options: Dictionary <String, AnyObject> 
           = [ kCGImageSourceThumbnailMaxPixelSize as String: 360 as AnyObject,
               kCGImageSourceCreateThumbnailFromImageAlways as String: true
                 as AnyObject,
               kCGImageSourceCreateThumbnailWithTransform as String: true
                 as AnyObject]
    let index = (subAssetIndex ?? 1) - 1
    
    guard let thumbnail 
           = CGImageSourceCreateThumbnailAtIndex(imageSource, 
                                                 index, 
                                                 options as CFDictionary?) 
        else
    {
        NSLog("Unable to generate thumbnail!")
        
        return nil
    }
    
    return NSImage(cgImage: thumbnail, size: NSZeroSize)
}
]]>
https://www.cocoanetics.com/2018/10/regression-cgimagesource-doesnt-render-background-image-of-certain-pdfs/feed/ 0 10586
Radar: [Xcode] Enabling Extension-safe API check changes generated ObjC-Header https://www.cocoanetics.com/2017/10/radar-xcode-enabling-extension-safe-api-check-changes-generated-objc-header/ https://www.cocoanetics.com/2017/10/radar-xcode-enabling-extension-safe-api-check-changes-generated-objc-header/#comments Tue, 03 Oct 2017 16:16:45 +0000 https://www.cocoanetics.com/?p=10531

Normally you only need the “Allow app extension API only” for extension targets, to get warned if you are accessing API which is not available for extensions. I had enabled it for a framework to make sure I didn’t call forbidden API.

I found this issue at the same time as this other issue because my client complained about both problems: Not seeing any documentation via Quick Help as well as the generated header unnecessarily containing internal classes. This problem was already present in Xcode 8, as evidenced by somebody asking about it on Stack Overflow.

Filed as rdar://34790796 and on Open Radar. The mentioned sample is on my Radar Samples GitHub repo, titled InterfaceTest.

Summary

For Swift-based frameworks/modules, Xcode generates an Objective-C header named Module-Swift.h. Ordinarily this only includes public classes. But if you turn on the “Allow app extension API only” setting, then also internal classes are included.

Steps to Reproduce

  1. Build the Module scheme of the provided sample app with Xcode 9
  2. Inspect the Module-Swift.h contained in the produced Module.framework
  3. You will see only the public classes CustomView and AncestorView
  4. Now turn on “Allow app extension API only” in the Module target build settings and build again
  5. Inspect the same header as in step 1.

Expected Results

  • The generated Objective-C header should be identical regardless of the state of this setting

Actual Results

  • With the setting off, only public classes are showing
  • With the setting on, you also see the internal class SwiftViewController

Version/Build

Xcode 9.0 (9A235)

Configuration

iMac or MacBook, with Xcode 9 and macOS 10.13

]]>
https://www.cocoanetics.com/2017/10/radar-xcode-enabling-extension-safe-api-check-changes-generated-objc-header/feed/ 2 10531
Radar: [Xcode] Quick Help no longer shows documentation from imported module https://www.cocoanetics.com/2017/10/radar-xcode-quick-help-no-longer-shows-documentation-from-imported-module/ https://www.cocoanetics.com/2017/10/radar-xcode-quick-help-no-longer-shows-documentation-from-imported-module/#comments Tue, 03 Oct 2017 15:02:26 +0000 https://www.cocoanetics.com/?p=10521 I found this new issue when developing a framework for a client. I have all Swift code in a module and added nice documentation comments to all of the public methods and properties.

In Xcode 8, you could Open+Click on any property, class or method and you would see the documentation from these comments. This would work regardless if you are in Swift or Objective-C code.

Now with Xcode 9 that suddenly doesn’t work any more from Objective-C code. In Swift files it still works, both in the module itself as well as an app importing it.

Filed as rdar://34789767 and on Open Radar. The mentioned sample is on my Radar Samples GitHub repo, titled InterfaceTest.

Summary

Documentation comments for a Swift class are displayed only within Swift code. Neither in same module, nor in an importing ObjC-class Quick Help works. The generated ObjC Header Module-Swift.h has the documentation comments present.

Steps to Reproduce

  1. Open the ObjcCViewController.m or the sample app with Xcode 9
  2. Open+Click on publicProperty

Expected Results

  • You should see “This is a public property” displayed in Quick Help

Actual Results

  • You only see “No Quick Help”
  • If you instead do the same in the SwiftViewController you see Quick Help as expected.

Version/Build

Version 9.0 (9A235)

Configuration

iMac or MacBook, with Xcode 9 and macOS 10.13

]]>
https://www.cocoanetics.com/2017/10/radar-xcode-quick-help-no-longer-shows-documentation-from-imported-module/feed/ 1 10521
Document Menu View Controller not Showing Locations https://www.cocoanetics.com/2017/05/document-menu-view-controller-not-showing-locations/ https://www.cocoanetics.com/2017/05/document-menu-view-controller-not-showing-locations/#respond Sun, 28 May 2017 18:28:29 +0000 https://www.cocoanetics.com/?p=10491 I’ve been testing and wanting to use PSPDFKit’s PDF Viewer ever since I signed up for the beta. But I had a weird issue opening PDFs from Dropbox or iCloud; I would only see the option to add a new PDF, but no way to import a PDF from the cloud.

Peter Steinberger sent me the code they use to show the UIDocumentMenuViewController as popover. There you can add custom options and you will see document providers which support the mode and file types you specified. I did only ever see the custom option.

I put his code into a sample app and was able to reproduce the problem on my main iPhone 7+. No providers were showing but instead the following was logged to the console:

[Assert] Passed in type com.adobe.pdf doesn’t conform to either public.content or public.item. If you are exporting a new type, please ensure that it conforms to an appropriate parent type.

A long time ago, I wrote about Fun with UTI, explaining that a UTI should always conform to both a type in the physical UTI hierarchy (with public.item as its root) and the functional UTI hierarchy (with public.content being the root). iOS claiming that PDF didn’t conform to either seemed odd to me.

So I printed out the UTI’s declaration with a function provided by MobileCoreServices.

let declaration = UTTypeCopyDeclaration(kUTTypePDF)!
print(declaration)

And got the following …

{
    UTTypeDescription = "my pdf viewer";
    UTTypeIdentifier = "com.adobe.pdf";
    UTTypeTagSpecification =     {
        "public.filename-extension" =         (
            pdf
        );
        "public.mime-type" =         (
            "application/pdf"
        );
    };
}

… but should have gotten this original declaration:

{
    UTTypeConformsTo =     (
        "public.data",
        "public.composite-content"
    );
    UTTypeDescription = "Portable Document Format (PDF)";
    UTTypeIconFiles =     (
        "pdf_20x20.png",
        "pdf_20x20@2x.png",
        "pdf_145x145.png",
        "pdf_145x145@2x.png"
    );
    UTTypeIdentifier = "com.adobe.pdf";
    UTTypeTagSpecification =     {
        "public.filename-extension" =         (
            pdf
        );
        "public.mime-type" =         (
            "application/pdf"
        );
    };
}

The latter declaration is the standard definition by iOS and it did show up on other test devices. PDF does not directly conform to public.content, but does so over an intermediate layer public.composite-content. This is “content with special formatting instructions”… a fancy way to say that it is not just plain text.

The former declaration was only present on my iPhone 7+. It lacked the essential UTTypeConformsTo section; thus it was not conforming to anything. So the above mentioned assert was perfectly correct.

So who’s fault was it?

Probably my own… about 7 years ago I was dabbling with rendering PDFs on iOS. I must have added this flawed declaration and specified the type name as “my pdf viewer”. Or – since I cannot remember doing that – maybe I tried out some sample code that did. For some unknown reason the flawed declaration persisted over 5 or 6 iPhones, because the faulty UTI gets restored with iCloud backup.

There were 3 ways to remedy this situation:

  1. Ignore it, because it was a dumb developer who messed up his iPhone’s UTI registry with some experiments.
  2. At runtime you could check if the UTI in question conforms to item or content. If it doesn’t you could show a warning.
  3. As a workaround you could define your own type that both conforms to PDF and content.

Regarding option 2, the UTTypeConformsTo can answer this question, even over 2 levels:

// check that PDF conforms to composite type
let conforms1 = UTTypeConformsTo(kUTTypePDF, kUTTypeCompositeContent)
print("\(kUTTypePDF) conforms to \(kUTTypeCompositeContent): \(conforms1)")
        
// check that composite type conforms to content
let conforms2 = UTTypeConformsTo(kUTTypeCompositeContent, kUTTypeContent)
print("\(kUTTypeCompositeContent) conforms to \(kUTTypeContent): \(conforms2)")

// check that PDF conforms to content
let conforms3 = UTTypeConformsTo(kUTTypePDF, kUTTypeContent)
print("\(kUTTypePDF) conforms to \(kUTTypeContent): \(conforms3)")

Regarding option 3, the following goes into info.plist. Then you can just specify com.cocoanetics.pdf as type to open.

<key>UTExportedTypeDeclarations</key>
<array>
<dict>
<key>UTTypeConformsTo</key>
<array>
<string>public.content</string>
<string>com.adobe.pdf</string>
</array>
<key>UTTypeDescription</key>
<string>Adobe PDF</string>
<key>UTTypeIconFile</key>
<string>FOO</string>
<key>UTTypeIdentifier</key>
<string>com.cocoanetics.pdf</string>
<key>UTTypeTagSpecification</key>
<dict>
<key>public.filename-extension</key>
<array>
<string>pdf</string>
</array>
</dict>
</dict> </array>

I did test if a simple reset of the settings would remedy the situation, but it didn’t work. Doing a reset and then restoring an iCloud back also caused the problem to reappear. Only when I wiped the iPhone and set it up as new device I was able to get back the origin UTI declaration for PDF.

Conclusion

Peter Steinberger kept telling me for many months that I was the only one that had this problem. And – of course – he was right. Some experiments of mine, several years ago, apparently destroyed the original UTI definition and only setting up my iPhone as a new device fixed the problem.

I don’t want to know what other crud had accumulated over the years when I always restored my previous iPhone’s backup to my new device. Also there were tons of apps that I didn’t use any more. So, good riddance. What a nice feeling to have a fresh and empty iPhone….

Update: I filed rdar://32446751 for it.

]]>
https://www.cocoanetics.com/2017/05/document-menu-view-controller-not-showing-locations/feed/ 0 10491
PSA: Xcode hanging opening projects https://www.cocoanetics.com/2017/01/psa-xcode-hanging-opening-projects/ https://www.cocoanetics.com/2017/01/psa-xcode-hanging-opening-projects/#comments Sat, 21 Jan 2017 19:19:59 +0000 https://www.cocoanetics.com/?p=10378 There is bug in Xcode 8 that has not yet been fixed as of Xcode 8.2.1. If you running macOS Sierra you might find that Xcode hangs if you try to open a project, for example via Finder or the open command. The original bug report was filed as rdar://29319747 which mine was closed as a duplicate of.

Rick Ballard, Xcode Software Engineering Manager at Apple, helped me find the reason for this weird issue. I provided a sample and spindump and from these he was able to determine that it was a case of RTFM. 🙂

Subsequently, upon reviewing the mentioned Xcode 8 release notes, I found not one but two issues with iCloud folders:

Known Issues

  • When an Xcode project is stored in iCloud Drive, Xcode does not automatically detect iCloud Drive sync conflicts for projects or for files involved in the build. Note that the Documents and Desktop folders can be stored in iCloud Drive on macOS 10.12. (18161353)
  • Opening Xcode projects and workspaces stored in iCloud Drive, or changing source control branches for an open workspace or project stored in iCloud Drive, may sometimes cause Xcode to hang. Note that in macOS 10.12, your Documents and Desktop folders may optionally be iCloud Drive locations. (28212905)

Up until this point I was keeping all my projects in ~/Documents/Projects. But since I want to make use of iCloud folders, yet not have Xcode being hanging itself every time I open one, I followed Rick’s advice: I moved all my projects to just ~/Projects.

iCloud folders are only available for Documents and Desktop, so any other location besides those not affected by this Xcode bug. I have not seen any other hanging since I moved the projects to the new place on all my machines.

 

]]>
https://www.cocoanetics.com/2017/01/psa-xcode-hanging-opening-projects/feed/ 1 10378
Sheet dismissal bug when window is hidden https://www.cocoanetics.com/2017/01/sheet-dismissal-bug-when-window-is-hidden/ https://www.cocoanetics.com/2017/01/sheet-dismissal-bug-when-window-is-hidden/#comments Wed, 18 Jan 2017 13:20:58 +0000 http://www.cocoanetics.com/?p=10359 Our customer found the following issue. In our apps we are showing some sheets for displaying progress to the user (downloading a bunch of images for example). I was not aware that if you ALT + CLICK in macOS ouside your window it gets hidden. When you do this and dismiss the sheet meanwhile an empty sheet remains on top of your window.

This bug is filed as rdar://30071930 and on Open Radar.

In the sample you can find on our Radar Samples GitHub Repo you can see the bug in action. This is how it should look:

and this is the empty sheet showing:

Summary

Sheet is not getting dismissed when window is hidden

Steps to Reproduce

  1. Run sample
  2. Click on Present Sheet button
  3. ALT + Click outside window to hide window
  4. Wait more than 5 seconds and click the app to show

Expected Results

  • Sheet should get dismissed

Actual Results

  • Empty sheet remains after dismissal

Notes

  • This happens on macOS 10.12 (Sierra)

The mentioned Sheet bug sample app is on our Radar Samples GitHub repo.

]]>
https://www.cocoanetics.com/2017/01/sheet-dismissal-bug-when-window-is-hidden/feed/ 1 10359
Use Legacy Swift Language Version https://www.cocoanetics.com/2016/12/use-legacy-swift-language-version/ https://www.cocoanetics.com/2016/12/use-legacy-swift-language-version/#comments Fri, 16 Dec 2016 15:14:09 +0000 https://www.cocoanetics.com/?p=10349 There is a bug in Xcode 8.2 that – after upgrading to this version – it is no longer able to build your project. The build error message is:

Use Legacy Swift Language Version” (SWIFT_VERSION) is required to be configured correctly for targets which use Swift.

We saw this in projects where we are not using any legacy Swift, i.e. everything is Swift 3. Also there is a project-wide setting to NOT use legacy Swift. The new bug seems to ignore the project-setting.

The error looks like this:

We set up the “Use Legacy Swift Language Version” to No on project level. In the “Levels” view of the build settings you can see this to be the case.

So – technically it should work, because if a setting is not specified on the target level, then the one from project-level would be used. Or rather, was used, until Xcode 8.1. The solution is to go in and specify the setting explicitly on all targets which use Swift. You need to see the value in bold to know that it is specified.

When you make this change, Xcode add SWIFT_VERSION = 3.0; to the project file for these targets.

Until Apple fixes this incorrect interpretation of the project-wide build setting for the Swift version setting, we will have to manually specify it on target-level ourselves.

 

]]>
https://www.cocoanetics.com/2016/12/use-legacy-swift-language-version/feed/ 1 10349
Bug: NSCollectionView Move Sections Crash https://www.cocoanetics.com/2016/09/bug-nscollectionview-move-sections-crash/ https://www.cocoanetics.com/2016/09/bug-nscollectionview-move-sections-crash/#respond Wed, 28 Sep 2016 14:20:59 +0000 https://www.cocoanetics.com/?p=10314 We are so foolhardy that we are using NSCollectionView in an internal project that gets widely used by an enterprise client of ours. We found this latest crashing bug while updating the application for macOS 10.12 wich is where the issue first appeared.

The only workaround at this time is to remove animation via animator() and replace it with a reloadData. Thus we vote NSCollectionView for worst Apple API on macOS.

This bug is filed as rdar://28337446 and on Open Radar.

Summary

When you move 1 section to another section NSCollectionView crashes on animation (for example 0 to 1)

Steps to Reproduce

  1. Run sample
  2. Press Move Section 0 down
  3. Crash on animation

Expected Results

  • Animation without crash

Actual Results

  • Crash

Notes

  • This sample works on 10.11 (El Capitan)
  • It crashes on 10.12 (Sierra)

The mentioned CollectionViewMoveBug sample app is on our Radar Samples GitHub repo.

]]>
https://www.cocoanetics.com/2016/09/bug-nscollectionview-move-sections-crash/feed/ 0 10314
LLVM Crash https://www.cocoanetics.com/2016/09/llvm-crash/ https://www.cocoanetics.com/2016/09/llvm-crash/#comments Thu, 15 Sep 2016 13:41:03 +0000 https://www.cocoanetics.com/?p=10305 I found this LLVM compiler crash when updating a project for building with Xcode 8. At first I thought it had to do with #if DEBUG because the crash didn’t occur when I removed the conditional compiling block. But further experimentation showed that it is a specific line in this block that is causing the issue.

It is filed as rdar://28318984 and on Open Radar.

Summary

The Xcode editor accepts the mentioned code as valid, but LLVM on building seg-faults.

Steps to Reproduce

Paste this line into a single-view iOS app:

try! JSONSerialization.data(withJSONObject: !, options: [])

Expected Results

  • Both the Xcode syntax checker as well as LLVM should report the parameter as invalid.

Actual Results

  • Xcode editor accepts the code as stated
  • LLVM seg-faults (see attached screenshot)

Version

Version 8.0 (8A218a), macOS 10.11.6 (15G31)

Notes

Might be coming from the first parameter’s type gotten changed to an Any in the the Grand Renaming. But it is a mystery to me why ! would be a valid Any.

LLVM Crash

]]>
https://www.cocoanetics.com/2016/09/llvm-crash/feed/ 1 10305
Enhancement: Make NSTextList Public https://www.cocoanetics.com/2016/09/enhancement-make-nstextlist-public/ https://www.cocoanetics.com/2016/09/enhancement-make-nstextlist-public/#comments Mon, 12 Sep 2016 06:28:25 +0000 https://www.cocoanetics.com/?p=10296 Whenever I am tasked with adding a rich text editor to an app, I check if Apple has since done something in UIKit to support lists. Since they revamped the text system in iOS 7, unifying large portions with how they are dealing with text on macOS, I am getting my hopes up for every new release of iOS.

macOS is using the NSTextList class to represent lists and the code below is provides proof that this class also exists on iOS. So this Radar requests – probably not for for the first time – for NSTextList to be made public. It is filed as rdar://28254852 and on Open Radar.

Summary

When parsing HTML into an NSAttributedString, your parser adds an NSTextList object when it encounters

<OL><LI>Item</LI></OL>.

and sets it on the (private) textLists property on NSParagraphStyle.

This request is to promote both the NSTextList class as well as the textLists property to public API.

Without this access we are not able to use UITextView for modern rich text editing. Every modern rich text editor allows inserting and updating of ordered/unordered lists.

Since NSTextList seems to have been available since iOS 7 we believe you could make it public retroactively in a minor update to iOS 10.

Steps to Reproduce

Paste the following into a Playground:

import UIKit

let body = "<ol><li>one</li></ol>"

let data = body.dataUsingEncoding(NSUTF8StringEncoding)
let options : [String: AnyObject] = [
NSDocumentTypeDocumentAttribute: NSHTMLTextDocumentType,
NSCharacterEncodingDocumentAttribute: NSUTF8StringEncoding
]

let attribStr = try! NSAttributedString(data: data!, options: options, 
                                        documentAttributes: nil)
print(attribStr)

Expected Results

The print shows that there is an NSTextList object present. But there is no public API to work with it.

Actual Results

I would expect to be able to access the textLists property of the paragraph style.

Proof for NSTextList on iOS

]]>
https://www.cocoanetics.com/2016/09/enhancement-make-nstextlist-public/feed/ 1 10296
NSLog crashes with certain NSURLs https://www.cocoanetics.com/2016/01/nslog-crashes-with-certain-nsurls/ https://www.cocoanetics.com/2016/01/nslog-crashes-with-certain-nsurls/#comments Fri, 29 Jan 2016 09:22:43 +0000 https://www.cocoanetics.com/?p=10043 This is a bug in NSURL which managed to astonish me. Even as a seasoned developer you can only but marvel at the easy way to reproduce it and wonder what might be the reason for it happening.

A client reported that our app was crashing. When I launched the app in debugger I expected to see the exception to be something obvious, like a nil being unwrapped. But it turns out that there is a bug in NSLog. Filed as Radar rdar://24406969 and on Open Radar.

Summary

Some NSURLs are able to crash an app with EXC_BAD_ACCESS.

Steps to Reproduce

Add the following two lines to a new empty iOS app.

let URL = NSURL(string: "http://files.parsetfss.com/fa80bc63-88d4-412d-a478-2451cffc92a9/tfss-1d2a321d-b02e-4745-a589-e31536f648df-XXXXX%20CAT15%2030.p0001.jpg")
NSLog("Loading page with URL: \(URL)")

Run and weep.

Expected Results

The URL should be logged.

Actual Results

The app crashes with EXC_BAD_ACCESS as shown in the attached screen shot

Notes

This is the kind of crash that both delights and amuses. 😉

NSLog Crash

Note: As a workaround I tried absoluteString, but this also causes the crash to occur. Logging scheme, host and path individually seem to work. But better to remove the logging of NSURLs for the time being.

]]>
https://www.cocoanetics.com/2016/01/nslog-crashes-with-certain-nsurls/feed/ 4 10043
The Case of the Missing Translation https://www.cocoanetics.com/2015/11/the-case-of-the-missing-translation/ https://www.cocoanetics.com/2015/11/the-case-of-the-missing-translation/#comments Thu, 05 Nov 2015 12:19:57 +0000 https://www.cocoanetics.com/?p=9962 Since iWoman was acquired by FOKUS KIND Medien we have been working on a complete UI overhaul. This also requires many new translations. The previous version of iWoman had been localized with Linguan, a Mac app which we also had sold a while ago. Unfortunately Linguan does not yet have support for XLIFFs, even though the new owner is considering it.

This blog post describes an issue that the XLIFF workflow has because of a bug on POEditor.com as well as a problematic “feature” in Xcode which causes some strings to go missing.

At WWDC 2015 I was told by the guys responsible for localization at Apple that they consider strings files as a byproduct of the proper way to do localization this day. Apparently nowadays you don’t mess with strings files any more, but rather with XLIFF files. XLIFF is short for XML Localization Interchange File Format.

XLIFF solves an issue that has plagued the strings based workflow for quite some time: it also contains information of which file the localizations belong to. This way you can have multiple string tables contained in one XLIFF file per language and Xcode knows where a translation goes.

Extraction

The first step is to get Xcode to extract the localization tokens. You don’t even have to localize any files just yet. In this sample I have only set up a complex view controller and have not added any localization yet.

iWoman OnBoarding in IB

To get the XLIFF file, in Project Navigator, click on the project root and select the menu option Editor – Export for Localization …

Then select a place for the folder where Xcode should put the XLIFF files. You also have an option to select only the development language or to also include other languages (if you have added any). This got me an en.xliff file looking like on the following screenshot. Note the source text for the two paragraphs in the middle which I have highlighted.

en.xliff export

You got to appreciate the beauty of the structure! Under the xliff root node you have a node for each file. And under each file you have a trans-unit for each string. Each translation unit has an id which matches the Object ID in Xcode. The source node contains the string you put into Interface Builder and note contains some supplementary information, repeating text, ObjectID and the object’s class name.

As you can see I have two newlines between the two paragraphs in the longer introductory text. Those are also present in the source node and show escaped as \n in the note. This will become important for the mystery which is about to unfold.

Import to POEditor.com

When I asked around for recommendations about how to get these XLIFF files translated, POEditor.com was much praised and so we set up an account with them. The praise themselves as one of the very few who can even handle XLIFF files.

We got one of these now, let’s make a new project and get it properly imported. I created a new project via the POEditor dashboard:

POEditor after new project

As suggested by “To start, add a language” – I click the button to Add Language to add a language. My development language is English, so I add that at this point.

This new language does not have any “available terms” just yet, we need to import these from our en.xliff we produced in the first step. In the dark vertical bar on the right side, choose the upward arrow button which shows “Import Terms” once you hover over it.

A few options need to be set for our kind of XLIFF.

POEditor import options

We don’t just want to import the tokens, we also want the English texts. The texts in the UI so far might not be the ones we want to show up in the final app, since they are developer texts. As we seen above there is nothing in the target nodes of our XLIFF file. This is why we choose to “get translations from <source> instead of <target> tag”.

Clicking “Import File” we get two messages:

Successful Import

The second is of particular importance. The project needs a default reference language because this is what translators will see as source text. It also is necessary to have a reference language set because otherwise the XLIFF files you will export later would have empty source tags. And this is the the second piece to the unfolding mystery.

So we click the “Ok, let’s do it” button to make English the default reference language. We see the English translations screen and here we witness a case of data corruption.

POEditor lost the newlines

Comparing this text with the one highlighted in the original XLIFF, it becomes apparent that POEditor removed the newlines from the text imported from the source tag. Oh no!

I wonder why POEditor does not like newlines. In my case they saved me from having to do do two separate labels, one per paragraph. I would imagine that other developers think the same way.

Translate and File

Let’s pretend for now that all is well, not having any knowledge of what will follow. We add a new Language German and translate almost all the items there:

Translated the stuff

The translation shows the English reference text above ours and we fill in the German translation below it, again making a paragraph break with two newlines. The export button in the sidebar (downward array pointing to hard disk) gives us an “iOS XLIFF” file.

Let’s look at the resulting translation unit.

Source tag missing \n

As we can see – plain as day if your nose it put right to it by an annoyed developer – the source node no longer contains any newlines but reflects the text as it showed in the English translations.

In an earlier experiment I had not set a reference language. In that case the source tag is present but empty. We also see that POEditor escapes newlines in translations to \n, also something that Xcode does not seem to do.

Which is correct? Should newlines in strings be escaped as \n or not? The XML does not care.

Incomplete Import

Continuing our assumption that we don’t know anything about the missing newlines, we can now simply import the German translation into Xcode. Note that we haven’t added any localization languages to Xcode so far. Editor – Import Localizations …

Xcode will show us a before and after picture. There it looks like the two paragraph text is shown at the right place. On the left side you have “No Translation”, on the right you have the new German text.

Xcode localization diff

BUT … if we look at the newly generated Main.strings (German) we get disappointed. If you enable English localization for the Main.storyboard we see that we should have 5 translated items, but here we only have 4. But on this newly created strings file the multi-paragraph text is missing.

Missing strings

I experimented a bit on how I would have to change the German XLIFF so that the translation gets accepted by Xcode. It turns out that the source text needs to be exactly as it is in Interface Builder, including non-escaped newlines. Even if the newlines where there but \n\n then the translation would still be missing.

Conclusion

This mystery is solved! There are several issues that work together so that in the end some strings might simply be missing from your localizations…

Bug 1: POEditor.com should not change the source strings in any way. Especially it should not simply delete newlines as those might have some significance.

Bug 2: This depends on whether or not you should slash-escape source strings in XLiFF files. If yes, then this is a bug in Xcode as this is clearly missing. rdar://23410569

Bug 3: Xcode should not consider the source string for assigning translations to objects. The identifier of the translation unit should be the only key considered because it is likely that the source text will either be changed (to make it more user friendly) or carry different escaping coming back from the translation service. rdar://23410520

After reporting this to POEditor I received word back from them:

We’re aware of this case and we went through endless discussions about this when we implemented the .iOS XLIFF format. The documentation on XLIFF implementation is scarce at best and as a result we had to make a lot of research for this feature.

The good news is that POEditor does not ignore non-escaped new lines, but only if xml:space=”preserve” is set on the ‘file’ tag or the ‘trans-unit’ tag.

Since Apple doesn’t say anything about this, we had to rely on the general XLIFF standard (declared in the headers of the .iOS XLIFF as well) when we wrote the specs.

I’ve added this note to the Radar mentioned for Bug 2.

]]>
https://www.cocoanetics.com/2015/11/the-case-of-the-missing-translation/feed/ 9 9962
TestFlight builds might get stuck in “Processing” https://www.cocoanetics.com/2015/11/testflight-builds-might-get-stuck-in-processing/ https://www.cocoanetics.com/2015/11/testflight-builds-might-get-stuck-in-processing/#comments Thu, 05 Nov 2015 10:03:39 +0000 https://www.cocoanetics.com/?p=9957 Old story: you submit a new version of an app only to find the next day that you still have a place where a crash occurs. In my case I “developer rejected” the review submission and uploaded a new build. Only to find that 19 hours later – on the next day – it is still not available to be attached to the version for submission.

People on Twitter told me that they are having the same issues too every now and then. Apparently for some they can jigger it lose by refreshing the TestFlight iOS-Builds page every few seconds. A few individuals even do that with a chrome extension that reloads the page every 15 seconds.

So, time for a Radar: filed as rdar://23409291 and on OpenRadar.

Summary

When uploading builds to TestFlight from Xcode, it might occur that a build shows up, but does not get available for testing. If you click on “Show all builds” the build shows as still “Processing”.

Right now I have one build processing for 19 hours now, a newer one for 4 hours.

My twitter followers tell me that they have the same problem and the might be a workaround by refreshing the page every 15 seconds for a while to jigger it to finish processing eventually. However when I tried to refresh it several times, this did not have an effect for me

Steps to Reproduce

  1. Upload a TestFlight build
  2. Note the time it takes for it to become available for Internal Testing

Expected Results

  • the build should leave the Processing stage after no more than one hour, preferable within minutes

Actual Results

  • some builds take considerably longer than one hour
  • they show as Processing even after more than 10 hours

I am attaching a screenshot that shows prod.ly builds #563 and #564 being stuck in Processing.

Bildschirmfoto 2015-11-05 um 10.54.16

Notes

Maybe you should run a query on your backend to check which builds are in Processing for longer than a certain time. Most likely you will find that there is a bug in iTunes Connect that causes some builds to get stuck.

]]>
https://www.cocoanetics.com/2015/11/testflight-builds-might-get-stuck-in-processing/feed/ 1 9957
Table View Cells lose clickability in Today Widget https://www.cocoanetics.com/2015/10/table-view-cells-lose-clickability-in-today-widget/ https://www.cocoanetics.com/2015/10/table-view-cells-lose-clickability-in-today-widget/#comments Wed, 28 Oct 2015 18:10:28 +0000 https://www.cocoanetics.com/?p=9945 While working on a today widget I stumbled on a bug in iOS. Since I was using multiple rows I had changed my widget to be table view-based with multiple rows showing a label and a value. Oddly, this setup caused my table view cells to no longer highlight when being touched between the labels.

There is a workaround of course, see below, but it is ugly. Filed as rdar://23298579 and on Open Radar. The mentioned sample app is WidgetTabCellTest on my Radar Samples repo on GitHub.

Summary

You can use a table view as base for a Today Widget. iOS will magically do some setup, like remove the background color and set the correct effect on the separators.

BUT: Some of this magic causes cells to no longer responds to taps outside of the areas which are covered by textLabel and detailTextLabel.

This is even more of a problem if you use the “Right Detail” cell because then a large space opens up between the labels which is not responsive. Also we are supposed to left-align the table view contents with the widget title, which causes a large unresponsive area in the left margin.

A workaround is to set a background color on the cells with an alpha of at least 0.01 – but you should be required to do that.

Steps to Reproduce

  1. Launch the Today Widget of the provided sample app in Simulator
  2. You see three rows.
  3. On the first row you see that the selection highlight shows if you tap inside the text label, but not if you tap outside left or right of it
  4. On the second row, which is a .Value1 style, the area in the middle does not react to touches
  5. On the third row I have added a 99% translucent background color as a workaround, this way you can tap anywhere and the selection highlight shows

Expected Results

All rows should highlight regardless of where you touch them

Actual Results

Without the workaround the cells only highlight if you tap in the areas covered by labels.

Screen Shot 2015-10-28 at 19.09.01

 

]]>
https://www.cocoanetics.com/2015/10/table-view-cells-lose-clickability-in-today-widget/feed/ 1 9945
Radar: UITableViewAutomaticDimension https://www.cocoanetics.com/2015/08/radar-uitableviewautomaticdimension/ https://www.cocoanetics.com/2015/08/radar-uitableviewautomaticdimension/#respond Fri, 14 Aug 2015 10:15:36 +0000 http://www.cocoanetics.com/?p=9850 For an event calendar I am showing a table view with dynamically sized cells. There are two labels which can span multiple lines. Unfortunately automatic sizing of the cell height via UITableViewAutomaticDimension does not work consistently in iOS 8 and 9.

Filed as rdar://22193223 and on OpenRadar.

Tableview automatic dimension might truncate labels until first cell reuse

Summary

I have a cell that has a variable height label for the first line. I found that using automatic dimension some of the cells are sized incorrectly causing this label to be truncated. If I reloadData in viewDidAppear, the size becomes correct.

Steps to Reproduce

  1. Look at the two screen shots provided
  2. Notice that in one the bold label shows the …

The screen shot with the earlier time stamp is without the workaround, the one with the later time stamps has the reloadData as discussed.

Cut Off

Not Cut Off

Expected Results

There should always be all lines visible of the text on the bold label

Actual Results

Some cells (even off screen) get an incorrect size. Only if you reload the cells AFTER the view has appeared on screen the size becomes correct.

Notes

I believe that this Stack Overflow question describes the same issue.

When Apple asked me if the problem still occurred on the latest iOS 9 seed, I pulled the essential bits from my app into a sample: AutomaticHeightBug on my Radar Samples GitHub repo. There I use the same table view cell – configured in storyboard – as in the app from which the above screen shots came.

Not only does this show that the problem still exists in iOS 9 (SDK and/or device) but it also demonstrates how even exactly the same text results in different automatic row heights.

Mixed Cut Off Sample

The sample though puzzles me insofar as that there it is always the bottom right label that experiences the truncation. Also, reloading the table view doesn’t magically fix the layout as it does in my app. But at least the core issue is demonstrated by it: Labels with a vertical compression resistance of 1000 should never be truncated like shown.

I am aware of different ways how people are trying to work around this bug: calling layoutIfNeeded, setting the cell frame and reloading the table view. But my point is, those should not be necessary. This issue – which is present even in iOS 8 – should finally be resolved.

]]>
https://www.cocoanetics.com/2015/08/radar-uitableviewautomaticdimension/feed/ 0 9850
Radar: Web-To-Native Handoff broken https://www.cocoanetics.com/2015/08/radar-web-to-native-handoff-broken/ https://www.cocoanetics.com/2015/08/radar-web-to-native-handoff-broken/#comments Sun, 09 Aug 2015 13:05:16 +0000 http://www.cocoanetics.com/?p=9843 For our prod.ly app and website I implemented all 3 features that need a site association file. One of these is the ability to look at a page from the website on your Mac and then handoff to your native app on your iOS device.

Unfortunately this appears to be broken in iOS 9. Doing the same on an iPhone running iOS 8 this works perfectly. Filed as rdar://22204950 and on Open Radar.

Update Oct 4th: Fixed in iOS 9.1.

Web-To-Native Handoff broken on iOS 9

Summary

For our app I implemented Web-To-Native Handoff. This works perfectly on iOS 8, but on iOS 9 only Safari is suggested to accept the handoff.

Steps to Reproduce

  1. Have correctly constructed and signed apple-app-site-association file on your server
  2. Implement the app delegate method for handling handoff
  3. Install the app on an iOS 8 and an iOS 9 device
  4. On a Mac open a web page belonging to your domain
  5. Wake the iOS 8 and the iOS 9 device by pushing the power button

Expected Results

  • in the bottom left corner you should see your native app’s icon
  • if you pull this icon upwards the handoff should occur and your app show the corresponding page, regardless off iOS version
  • if the app is not installed then – of course – Safari shows and you can browse the same page in Mobile Safari

Actual Results

  • on iOS 8 the expected behavior occurs
  • on iOS 9 only Safari shows for accepting handoff, even if you have the native app installed

on iOS 9 the following lines appear in the console log:

Aug  3 16:35:13 Olivers-iPhone-6 SpringBoard[4828] : -[UABestAppSuggestionManager notifyBestAppChanged:type:options:bundleIdentifier:activityType:dynamicIdentifier:when:
confidence:deviceName:deviceIdentifier:deviceType:] D07B3CCE-B179-4619-8336-FB5299457BB1 UserActivity com.apple.mobilesafari/NSUserActivityTypeBrowsingWeb opts={
    } when=2015-08-03 14:35:13 +0000 confidence=1 from=Oliver's iPad Air/3BF1804F-4200-4893-A739-A1BB043F6DBC (UABestAppSuggestionManager.m #319)

Notes

Judging from the UABestAppSuggestionManager notice, the code to determine the suitable app for continuing the activity has been changed. iOS 9 determines the “best app suggestion” to always be Mobile Safari. And this is incorrect.

This photo shows the test: I’ve opened a prod.ly product page on my Mac. Have a look at the handoff icons showing on my test devices.

iOS 9 Handoff Issue

]]>
https://www.cocoanetics.com/2015/08/radar-web-to-native-handoff-broken/feed/ 1 9843