Of course I had to immediately file a bug report. It is slightly bit hilarious that Mobile Safari would crash on my own site. Looks like it’s somehow running out of “rpages”, whatever that means.

Filed as rdar://13885055 and on Open Radar.

Summary

When zooming into the left-hand sidebar on http://www.cocoanetics.com/apps/linguan/ MobileSafari reaches the per process limit of rpages and gets terminated by iOS.

Steps to Reproduce

• In MobileSafari, go to http://www.cocoanetics.com/apps/linguan/
• Zoom into the region on the left side titled “Updates”

Expected Results

• The tiling should created higher resolution tiles and the display become crisp

Actual Results

• After a second or so the app gets terminated and the following crash report logged

Incident Identifier: BAC656CD-EF31-453F-AC4A-AE1E1C8263FC
CrashReporter Key:   10d06614c22e25053f76586bd110cdfa0ced43f0
Hardware Model:      iPhone5,2
OS Version:          iPhone OS 6.1.4 (10B350)
Kernel Version:      Darwin Kernel Version 13.0.0: Wed Feb 13 21:40:10 PST 2013; root:xnu-2107.7.55.2.2~1/RELEASE_ARM_S5L8950X
Date:                2013-05-14 10:38:24 +0200
Time since snapshot: 102 ms

Free pages:        1489
Active pages:      8333
Inactive pages:    4370
Throttled pages:   151442
Purgeable pages:   0
Wired pages:       93689
Largest process:   MobileSafari

Processes
     Name                                           rpages       recent_max       [reason]          (state)

       MobileSMS          4349             4349                      (background)
      MobileMail         16656            16656                      (continuous)
     MobilePhone          3598             3598                      (continuous)
      librariand           316              316                      (daemon)
            tccd           335              335                      (daemon)
             kbd           569              569                      (daemon)
    MobileSafari        167691           167691  [per-process-limit] (frontmost) (resume)
            ptpd          1158             1158                      (daemon)
     dataaccessd          1589             1589                      (daemon)
           wifid           460              460                      (daemon)
   iaptransportd           301              301                      (daemon)
       locationd          1513             1513                      (daemon)
      aosnotifyd           517              517                      (daemon)
    mediaserverd          2164             2164                      (daemon)
         syslogd           172              172                      (daemon)
     SpringBoard         13124            13124                     
      backboardd         36064            36064                      (daemon)
         configd           774              774                      (daemon)
       lockdownd           868              868                      (daemon)
          powerd           163              163                      (daemon)
   mDNSResponder           271              271                      (daemon)
   fairplayd.N42           548              548                      (daemon)
  UserEventAgent           821              821                      (daemon)
         keybagd           149              149                      (daemon)
springboardservi             0                0                      (daemon)
    syslog_relay             0                0                      (daemon)
            afcd           205              205                      (daemon)
       gputoolsd             0                0                      (daemon)
   syncdefaultsd           494              494                      (daemon)
             ubd           747              747                      (daemon)
notification_pro           198              198                      (daemon)
filecoordination           200              200                      (daemon)
       distnoted           132              132                      (daemon)
            apsd           375              375                      (daemon)
      aggregated            98               98                      (daemon)
        networkd           201              201                      (daemon)
       fseventsd           375              375                      (daemon)
        BTServer           506              506                      (daemon)
         imagent           666              666                      (daemon)
      CommCenter          2089             2089                      (daemon)
         notifyd           222              222                      (daemon)
     ReportCrash           307              307                      (daemon)

**End**

Filed as rdar://13836932 and on OpenRadar.

Update May 9th: Provided a Sample App, which is also available on GitHub.

Summary

You can set a view as inputView for a editable view to appear in place of a keyboard. If this inputView has a scroll view this will erroneously receive a setContentInset after the keyboard finished its incoming animation.

Steps to Reproduce

• Create a UITableViewController
• On a UIView that canBecomeFirstResponder set this VC’s view as inputView
• have the UIView becomeFirstResponder

Expected Results

• The UITableViewController’s tableView should not have a contentInset

Actual Results

• Every UIScrollView receives a contentInset, even if it is itself the inputView that was showing “as keyboard”.

Regression

• This automatic setting of contentInset started with iOS 6. It does not occur in iOS 5.

Notes

I believe that the notification that gets sent after the keyboard/inputView animated in should take into consideration that scroll views that are subviews of the showing inputView don’t get a contentInset set.

As a workaround I am subclassing UITableView and overriding setContentInset: to ignore the erroneous setting.

This is the call stack I get on this overwritten contentInset:

* thread #1: tid = 0x1c03, 0x0000f6ca RTEDemoApp`-[DTFormatTableView setContentInset:](self=0x099e5000, _cmd=0x09405f60, contentInset=(null)) + 58 at DTFormatTableView.m:16, stop reason = breakpoint 3.1
frame #0: 0x0000f6ca RTEDemoApp`-[DTFormatTableView setContentInset:](self=0x099e5000, _cmd=0x09405f60, contentInset=(null)) + 58 at DTFormatTableView.m:16
frame #1: 0x0373c1bd CoreFoundation`__invoking___ + 29
frame #2: 0x0373c0d6 CoreFoundation`-[NSInvocation invoke] + 342
frame #3: 0x016c7def Foundation`NSKVOForwardInvocation + 375
frame #4: 0x03737cf9 CoreFoundation`___forwarding___ + 905
frame #5: 0x0373794e CoreFoundation`_CF_forwarding_prep_0 + 14
frame #6: 0x00bc5029 UIKit`-[UIScrollView(UIScrollViewInternal) _adjustForAutomaticKeyboardInfo:animated:lastAdjustment:] + 377
frame #7: 0x00c14ddc UIKit`-[UITableView(UITableViewInternal) _adjustForAutomaticKeyboardInfo:animated:lastAdjustment:] + 73
frame #8: 0x00d87af9 UIKit`-[UITableViewController _adjustTableForKeyboardInfo:] + 201
frame #9: 0x00d86c27 UIKit`-[UITableViewControllerKeyboardSupport _keyboardDidChangeFrame:] + 131
frame #10: 0x016d44f9 Foundation`__57-[NSNotificationCenter addObserver:selector:name:object:]_block_invoke_0 + 40
frame #11: 0x037a20c5 CoreFoundation`___CFXNotificationPost_block_invoke_0 + 85
frame #12: 0x036fcefa CoreFoundation`_CFXNotificationPost + 2122
frame #13: 0x01608bb2 Foundation`-[NSNotificationCenter postNotificationName:object:userInfo:] + 98
frame #14: 0x00f08a29 UIKit`-[UIInputViewTransition postNotificationsForTransitionEnd] + 682
frame #15: 0x00f01e5c UIKit`__53-[UIPeripheralHost(UIKitInternal) executeTransition:]_block_invoke_01079 + 203
frame #16: 0x00ba2df6 UIKit`-[UIViewAnimationBlockDelegate _didEndBlockAnimation:finished:context:] + 223
frame #17: 0x00b95d66 UIKit`-[UIViewAnimationState sendDelegateAnimationDidStop:finished:] + 237
frame #18: 0x00b95f04 UIKit`-[UIViewAnimationState animationDidStop:finished:] + 68
frame #19: 0x006a57d8 QuartzCore`CA::Layer::run_animation_callbacks(void*) + 284
frame #20: 0x01ff0014 libdispatch.dylib`_dispatch_client_callout + 14
frame #21: 0x01fe07d5 libdispatch.dylib`_dispatch_main_queue_callback_4CF + 296
frame #22: 0x036eeaf5 CoreFoundation`__CFRunLoopRun + 1925
frame #23: 0x036edf44 CoreFoundation`CFRunLoopRunSpecific + 276
frame #24: 0x036ede1b CoreFoundation`CFRunLoopRunInMode + 123
frame #25: 0x02b757e3 GraphicsServices`GSEventRunModal + 88
frame #26: 0x02b75668 GraphicsServices`GSEventRun + 104
frame #27: 0x00b57ffc UIKit`UIApplicationMain + 1211
frame #28: 0x00001fec RTEDemoApp`main(argc=1, argv=0xbffff208) + 92 at main.m:15

At first glance I assume that you would want to modify _adjustForAutomaticKeyboardInfo:animated:lastAdjustment: to check if the UITableViewController’s view is part of the view hierarchy of the inputView that triggered the inputView frame size change notification.

The workaround is to override the readFromURL:error: method of UIDocument instead loadFromContents:ofType:error: since the problem lies inside NSFileWrapper. While being very convenient to use on smaller documents having too many items inside an NSFileWrapper will cause the problem described in this bug report.

Filed as rdar://13586175 and on Open Radar.

Summary

Frequent opening and closing of a UIDocument subclass (not using iCloud) leads to a silent termination of the app.
Steps to Reproduce:

• have UIDocuments with hundreds of images in them
• open these UIDocuments and close them several times until the app is just gone

Expected Results

The app should not be terminated with signal 9. In the least a useful crash report should be created.

Actual Results

App is killed with signal 9, on the console this output is logged:

Apr 5 15:47:22 Stefan-Gugarels-iPad iCatalogTest[2700] <Error>: shared connection error: Connection interrupted
Apr 5 15:47:22 Stefan-Gugarels-iPad com.apple.launchd[1] (com.apple.librariand[2672]) <Notice>: (com.apple.librariand) Exited: Killed: 9
Apr 5 15:47:23 Stefan-Gugarels-iPad com.apple.launchd[1] (com.apple.tccd[2681]) <Notice>: (com.apple.tccd) Exited: Killed: 9
Apr 5 15:47:23 Stefan-Gugarels-iPad com.apple.launchd[1] (UIKitApplication:com.int-color.icatalogtest[0x114b][2700]) <Notice>: (UIKitApplication:com.int-color.icatalogtest[0x114b]) Exited: Killed: 9
Apr 5 15:47:23 Stefan-Gugarels-iPad com.apple.debugserver-199[2698] <Warning>: 1 +0.000000 sec [0a8a/1303]: error: ::read ( 5, 0x1c89fc, 18446744069414585344 ) => -1 err = Bad file descriptor (0x00000009)
Apr 5 15:47:23 Stefan-Gugarels-iPad backboardd[26] <Warning>: Application 'UIKitApplication:com.int-color.icatalogtest[0x114b]' exited abnormally with signal 9: Killed: 9
Apr 5 15:47:23 Stefan-Gugarels-iPad kernel[0] <Debug>: vnode: table is full
Apr 5 15:47:23 Stefan-Gugarels-iPad kernel[0] <Debug>: 1250 desired, 1250 numvnodes, 0 free, 0 dead, 0 rage
Apr 5 15:47:23 Stefan-Gugarels-iPad kernel[0] <Debug>: vnode: table is full
Apr 5 15:47:23 Stefan-Gugarels-iPad kernel[0] <Debug>: 1250 desired, 1250 numvnodes, 0 free, 0 dead, 0 rage
Apr 5 15:47:23 Stefan-Gugarels-iPad kernel[0] <Debug>: vnode: table is full
Apr 5 15:47:23 Stefan-Gugarels-iPad kernel[0] <Debug>: 1250 desired, 1250 numvnodes, 0 free, 0 dead, 0 rage
Apr 5 15:47:23 Stefan-Gugarels-iPad kernel[0] <Debug>: vnode: table is full
Apr 5 15:47:23 Stefan-Gugarels-iPad kernel[0] <Debug>: 1250 desired, 1250 numvnodes, 0 free, 0 dead, 0 rage

We suspect that this is a bug in the iOS SDK.

Regression

The problem started to occur when we switched to a UIDocument-based subclass for our document.

Notes

I am using multiple UIDocuments for displaying Catalogs. I open UIDocuments show them and close them. I am repeating the previous step until the app is killed with signal 9. (But i get no Crashlog and no Exception during Debugging). The only hint for me is found in iPad Console of device.

We verified that the UIDocument is being deallocated after showing. We are not using file presentation, but only the asynchronous loading facilities of UIDocument. We are not using iCloud and we do not need to save the UIDocument.

The out of vnodes condition seems to be related to using the NSFileWrapperReadingImmediate reading option of NSFileWrapper since we are able to show the termination both with an explicitly created file wrapper with this option as well as UIDocument. UIDocument appears to be using the same file wrapper reading option internally.

If we change the reading option to NSFileWrapperReadingWithoutMapping then the problem no longer occurs.

Even if this is “by design” then in the least we would expect for a useful exception to be raised such that an unsuspecting developer would have a clue how to work around that.

I noticed then when I was investigating why skipping in some of my own podcasts didn’t work. Turns out that the reason for that was a combination of ngnix + WordPress Multi-User + one pesky rewrite rule. But this is not the root cause that some podcasts are having.

If you know how to read (and understand HTTP headers) let me know in the comments if you spot a possible explanation for this bug.

Filed as rdar://13490726 and on Open Radar.

iTunes 11.0.2: Skipping Ahead Broken in Some Podcasts

Summary

Skipping forward in mp3 podcasts is broken.

Steps to Reproduce

• In iTunes: File – Subscribe to Podcast, enter http://leoville.tv/podcasts/twit.xml
• double click on any older podcast episode, it will start to play at 00:00
• now click in the playing control progress track to try to skip to a later point

Expected Results

• playback should skip to the clicked position

Actual Results

• playback continues stubbornly, no HTTP ranged request for new position is sent

Regression

I checked 10 other podcasts and found a second one that has the same issue with iTunes. I can provide you with the list of my tests.

Notes

When you click on the track iTunes seems to be sending the Range: header to state the position requested on the podcasts that work. It does not make a difference whether or not the podcast uses m4a or mp3 format. Also Some do a redirect for tracking downloads, some don’t.

I also tested the same problematic podcasts with the iOS Podcasts app 1.2. There I cannot reproduce the problem.

It appears that some combination of redirection and/or headers in the response disable the random access functionality in iTunes for these specific podcasts and it no longer sends the range header.

The following examples are done with Charles debugging proxy.

Example of functioning communication

>>> request from start:

GET /audio/mbw/mbw0340/mbw0340.mp3 HTTP/1.1
Host: twit.cachefly.net
User-Agent: iTunes/11.0.2 (Macintosh; OS X 10.8.3) AppleWebKit/536.28.10
Accept: */*
Cache-Control: no-cache
Connection: close

<<< response:

HTTP/1.1 200 OK
Server	CFS 1228
Date	Sat, 23 Mar 2013 17:13:15 GMT
Content-Type	audio/mpeg
Connection	close
ETag	"7086e985aab6289a32b65ceec1ab6225"
X-CF1	dC.ams1:cf:cacheA.ams1-01
Content-Length	48421137
Last-Modified	Tue, 05 Mar 2013 23:08:26 GMT
X-CF2	L
Accept-Ranges	bytes

>>> skip ahead request

GET /audio/mbw/mbw0340/mbw0340.mp3 HTTP/1.1
Host: twit.cachefly.net
User-Agent: iTunes/11.0.2 (Macintosh; OS X 10.8.3) AppleWebKit/536.28.10
Accept: */*
Cache-Control: no-cache
Range: bytes=20236119-
Connection: close

<<< skip ahead response (OK)

HTTP/1.1 206 Partial Content
Server	CFS 1228
Date	Sat, 23 Mar 2013 17:13:19 GMT
Content-Type	audio/mpeg
Connection	close
ETag	"7086e985aab6289a32b65ceec1ab6225"
X-CF1	fC.iad2:cf:cacheB.iad2-01
Content-Length	28185018
Last-Modified	Tue, 05 Mar 2013 23:08:26 GMT
X-CF2	L
Content-Range	bytes 20236119-48421136/48421137

Example of non working skip ahead, different podcast

>>> Initial request from start

GET /twit/twit0393.mp3 HTTP/1.1
Host: aolradio.podcast.aol.com
User-Agent: iTunes/11.0.2 (Macintosh; OS X 10.8.3) AppleWebKit/536.28.10
Accept: */*
Cache-Control: no-cache
Connection: close

<<< Initial request response

HTTP/1.0 200 OK
Server: Apache
Last-Modified: Mon, 18 Feb 2013 04:50:23 GMT
ETag: "3e5e579-4d5f87677a1c0"
Accept-Ranges: bytes
Content-Length: 65398137
Content-Type: audio/mpeg
Cache-Control: max-age=7776000
Expires: Fri, 21 Jun 2013 19:52:23 GMT
Date: Sat, 23 Mar 2013 19:52:23 GMT
Connection: close

>>> at this point clicking in the progress bar does not send a new ranged request and skipping ahead does not work

Filed as rdar://13450321 and on Open Radar. Please dupe it if you agree.

Update Ruby shipped with OS X

Seriously I’m sick of my colleagues complaining that Apple has not updated the version of Ruby that ships with the OS X for 9 YEARS now.

ruby --version
ruby 1.8.7 (2012-02-08 patchlevel 358) [universal-darwin12.0]

According to Wikipedia Ruby 2.0 was released on February 24, 2013. Ruby 1.9 was released in December 2007.

I think most developers would be delighted if Apple updated the bundled Ruby to version 1.9, they would be ecstatic if Apple went “all-in” and adopted ruby 2.0 in the next major OS Version.

Please Apple, *PLEASE* this is really a request that causes little work (have an Intern do it!) but big rewards. Goodwill from the developer community, fame, wealth, good fortune, good karma…. and my ever lasting gratitude for having one less reason for people whine around me that you are supposedly boycotting any development language other than Objective-C.

The recently released Deploymate app scans your Xcode projects for such problems and flags them. This proves that such an analysis is possible and can be implemented. The developer of Deploymate confided that he hesitated to release for a long while since he feared that Apple might put exactly this functionality into Xcode. But they never did, so he created the app.

This Radar is my documented suggestion to Apple to finally add such functionality into Xcode. Worst case they should acquire the technology employed by Deploymate and add that. But I am quite certain that LLVM’s analysis capabilities should be able to put to this use as well.

Filed as rdar://13436964 and on OpenRadar.

Xcode: Provide Warnings if App might Crash on devices with previous iOS version

Compiling with “Latest SDK” allows developers to make use of new functionality in the latest SDKs, but if the deployment target allows for execution on earlier iOS versions then there are many scenarios where usage of new functionality or even constants might lead to a crash.

The IDE should detect scenarios where the developer forgot add the appropriate checks if functionality exists (e.g. respondsToSelector) and point out code where a crash is inevitable.

That such functionality is possible is proven by a newly released app called Deploymate (http://www.deploymateapp.com) which scans an Xcode project and flags such problems.

From personal experience I can say that even though we developers KNOW about having to check for these scenarios and also test on older supported iOS versions it DOES happen and the result is always embarrassment for having shipped an app that crashes. By baking such a tool into the Xcode IDE it would save us this embarrassment.

Update: I was made aware by an Apple engineer that Xcode is indeed already autosaving versions of your files as you make changes.  Versions is an OS X feature. But there is no Revert menu option in Xcode to access these saves. As a workaround you can open the source file in TextEdit and do the reverting there! A hidden feature that is so well hidden, it’s even in a different app!

Since 10.7 OS X has support for Auto Save and Versions. Xcode 4 doesn’t support these tool that are invaluable to people writing much text, like developers.

It happened to me yesterday that I accidentally reverted two files that I had been working on the entire day. That kind of thing can happen if it is late and you just want to finally commit your work to the SCM, but want to revert the modifications you made for testing.

I was saved by Time Machine in this instance because it had a version from half an hour ago. Still Xcode should support Auto Save and Versions – like any other good citizen on OS X – so that I can always go back to a specific auto-save.

Even better Xcode could integrate the auto-saves with the the version comparison tool allowing editing of the current version and copy/pasting code from older versions into the current one. The use case for this is that often I find myself going back several dozens of steps with Undo, copy something from the past, Redo back into the present and then insert the code.

So in summary Xcode should:

• files should be saved frequently and automatically as I manipulate them
• allow reverting back to earlier versions of files via Versions (Time Machine-like interface via File Menu)
• allow version comparison with local history in contrast to remote history coming from SCM

Other competing development environments like AppCode have this feature already, see the attached screen shot.

Please, I love Xcode and I don’t want to switch. But you’ll get the fifth star only if you implement this.

So after I copied the menu over for another app I found that I couldn’t find the redo: action to connect to the Redo menu item. Filed as Radar rdar://13113666 and cross-posted on Open Radar.

Summary

When creating a new Mac app the Interface Builder does not see several standard actions, amongst them redo:. This leads to developer confusion if you want to re-add an Edit menu because there is no redo action to connect to a Redo menu item.

Steps to Reproduce:

• Create a new Mac app
• view MainMenu.xib’s actions on First Responder
• several items, including redo: have an exclamation mark next to them
• delete the connection to redo and the item will disappear altogether

Expected Results

• There is an undo: action, so there should also be a redo: action
• I would expect to be able to connect a Redo menu item to a redo: action.

Actual Results

• There is no redo: action visible
• Instead the
• I need to create a custom action redo: to be able to make the connection

Regression

This is usually not noticeable because few people would remove the Edit menu.

Notes

As a workaround you can create a custom action named redo:. It does not seem to interfere with normal operation of the app. You can also remove the custom action after making the connection if you don’t mind the exclamation mark in the list of First Responder’s actions.

Filed as rdar://13059657

Summary

An NSBox displaying a horizontal line as subview of a layer-backed NSView does not size correctly.

Steps to Reproduce

• Have an NSView that you enable layer-backing on with setWantsLayer:YES
• In Interface Builder add a “Horizontal Line” element to this view
• Size it such that it goes the entire width of the superview and layout contraints are 0 px for left and right

Expected Results

• The horizontal line should keep sizing together with the superview

Actual Results

• The horizontal line only grows to around 1588px
• If you disable layer backing on the superview the behavior returns to normal

Regression

• Appears to be a problem with layer backing.

Notes

Possibly related to rdar://problem/13006140 where a text field background is not sized correctly in layer-backed mode.

But I guess we should consider it our duty as Mac developers to make sure that Apple knows about bugs for this platform. So finally here’s my Radar for it. rdar://13006140

NSTextField Redrawing of Background With Layer-Backing

Summary

When used as subview of a view that has layer-backing turned on then making it wider causes the background color to not fill the entire area of the control.

I am seeing this bug in a scenario where I have a text field in an inspector panel that I can change in width via an NSSplitView. I attached a screen shot of the bug how it appears on an empty text field without the workaround mentioned below.

Steps to Reproduce

• have an NSView that has layer-backing turned on
• add an NSTextField as a subview to that
• have layout constraints that fix the left and right margin between the text field and the superview
• enlarge the NSView

Expected Results

• the background color of the control should be filled consistently
• the amount of text in the textfield seems to play a role. If it is empty then the unfilled background stays. If not then it might get filled once the user release the mouse button

Actual Results

Only the part of the control that was visible before stays filled, the new space appearing on the right side does not have background filling

Regression

Only occurs in connection with layers.

Notes

As workaround I subclassed NSTextField and overwrite drawRect like this:

- (void)drawRect:(NSRect)dirtyRect
{
	[super drawRect:self.bounds];
}

This fixes the problem because the dirtyRect is too small.

I am disturbed by the disparity between the NSShadowAttributeName attribute (which can only hold a single NSShadow) and CSS where you can have multiple shadows. Because NSHTMLWriter simply copies these to the CSS style of a span it should be quite easy to to also let NSHTMLWriter take an array.

It’s not a very important feature to have, but hey … it would give me some peace of mind.

Filed as Radar#12908144.

Support multiple Shadows in NSHTMLWriter

The current implementation of NSHTMLWriter only supports a single shadow. This shadow is an NSShadow instance set with attribute key NSShadowAttributeName.

NSHTMLWriter maps those core text attributes to their CSS counterparts for display in e.g. UITextView. CSS supports multiple shadows, e.g.

<p style="text-shadow:0.2em 0.5em 0.1em #600,
 -0.3em 0.1em 0.1em #060,
 0.4em -0.3em 0.1em #006">Multiple Shadows</p>

My enhancement request is to allow the NSShadowAttributeName to also be an array of multiple NSShadow instances. Those would simply be transferred to the css style for the span.

This enhancement would make shadows work the same in HTML and CoreText.

UITextView uses Webkit for displaying attributed strings. Unfortunately Kerning is disabled on Webkit views unless you specify a certain CSS style.

If you look at the AV characters you can see how the version with Kerning enabled has the AV seem at a more natural distance while the lower line has an uncomfortably wide distance between them.

In the Radar (which I filed under #12889869) I argue that when setting text on UITextView via setAttributedString we developers expect for Kerning to be on by default since this is the way that is closest to how CoreText renders it.

Summary

When setting an attributedText on a UITextView the text is rendered with Kerning disabled.

Steps to Reproduce

Create a simple attributed string, e.g. “AV” in Times New Roman with 50 px font size

Expected Results

When setting this attributed string on a UITextView it should display the text with Kerning, as is the default when rendering this text via CoreText. For the example “AV” the right bottom of the A is overlapping the left top of the V.

Actual Results

Letters do not overlap making the text harder to read. Especially if using UITextView to display a longer text for reading it is bad to have Kerning disabled.

Regression

Support for NSAttributedText is new as of iOS 6.

Notes

Internally UITextView converts the attributed string to HTML via NSHTMLWriter and then displays it in a UIWebDocumentView. The default mode for this is to have Kerning disabled.

It can be enabled by the CSS style, which is mentioned here.

text-rendering: optimizeLegibility;

Having this not be the default also confuses developer, as you can see on this question on stack overflow.

I propose that when text is set via setAttributedText on UITextView to make this setting the default since as a developer we would expect the output to match CoreText as closely as possible.

This is one of many shortcomings of UIKit’s support for attributed strings. A workaround for this was described as having to omit font attributes from the attributed string. So you can either have multiple fonts and unchanging line height or only the font you set on the font property of UITextView.

Other people are having the same problem, as outlined by this question on StackOverflow.

Filed as rdar://12863734

Summary

If an attributed string contains both a font attribute as well as a paragraph style attribute that sets minimum/maximum line height those line height constraints are ignored.

Steps to Reproduce

Create an attributed string that contains a font and paragraph style attribute. Make sure the paragraph style attribute sets a minimum and maximum line height that is less than the font line height.
Set this attributed string on a UITextView’s attributedString property.

Expected Results

The lines should be spaced by the amount of the specified minimum/maximum.

Actual Results

The lines are spaced as they would be without the paragraph style settings.

Regression

UITextView only supports attributed strings since iOS 6. Since then this is broken.

Notes

The problem seems to result if you have multiple different fonts, like when you have some bold or italic text in the string.

Apple engineering asked for a sample app which I provided to them: minmaxlineheightbug.zip.

I also added those further findings:

I have attached a sample app that demonstrates the problem. Launch it and you see a selector at the top which sets the text view to a version with and without a font attribute.

For your convenience I did further research and found that the bug lies with NSHTMLWriter. You can see the two kinds of output in the lower text view, they only differ on the p.p1.

Compare the output for p.p1 (the first paragraph) for the version WITHOUT font:

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 40.0px}

and WITH font:

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 40.0px; font: 14.0px Helvetica}

The bug here is easy to miss, I also had to look up the font CSS shorthand.

The font shorthand sets BOTH the font-size as well as the line-height thus overruling the 40px. This is true both for UIWebView as well as Safari.

WORKAROUNDS:

If you change the order of items in p.p1, then it works:

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 14.0px Helvetica;line-height: 40.0px;}

Alternatively you can dispense with the font short hand and spell out all items, that works as well:

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 40.0px;font-size:14px;font-family:Helvetica;}

The problem appears if a PDF is using a CMYK color blending space on a page for transparency blending. That causes this effect. Left side is how the PDF comes out on Mac, right side how it looks correctly on iOS (Simulator/Device). Also if you view the PDF in Preview or Pixelmator it looks weird, only in Adobe’s tools do they look correct.

If the behavior were the same on Mac and iOS then I would have thought to be Adobe using some weird special extension, but since the output is correct on iOS we think that this must actually be a bug. Maybe the Mac version of Quartz PDF rendering tries to do something smart since it is aware of color calibration but doing so messes up the colors.

This is a bit embarrassing since one might think that Macs with all their color profiling and such would get the colors right, overtime. But this appears to be especially prevalent in the print industry which seems to like to use CMYK. Now the problem occurs if they want us developers to use the same PDFs that they created for printing. The only workaround I know of is to edit the PDF and modify the blending setting:

I filed it under Radar #12796443 as well as cross-posted it on OpenRadar.

Summary

If a PDF document has pages that have a page-level transparency blending color space of CMYK then all output on Mac using Quartz PDF drawing will have incorrect colors.

This affects drawing of PDFs via PDFKit, CGPDF functions, viewing in Preview and most third party apps, like e.g. Pixelmator. Adobe’s apps are the only ones the display it correctly.

Interestingly the rendering behavior on iOS – including the iOS simulator on Mac – displays those PDFs correctly.

Steps to Reproduce

Create a PDF with e.g. Adobe InDesign, have some transparent elements
Set the Page-Level Transparency Blending Color Space to CMYK
View this PDF in Preview.app

Expected Results

Colors should look the same viewing the PDF on Mac as well as iOS.

Actual Results

iOS (device and simulator) show correct colors, on Mac the colors look less brilliant and muddy.

Regression

n/a

Notes

If this were happening uniformly on iOS and Mac then we’d say that this might be a problem with Adobe using some weird extensions. But since the colors are correct on iOS, even in the Simulator, we think that OS X is trying to do the right thing with the blending color space, but this causes the colors to be output incorrectly.

This problem is most prevalent in the print industry because there CMYK is often as a default setting used instead of RGB. One would expect for Macs to get the colors right, being the tool of choice (even having color correction) for graphic designers worldwide.

Turns out that Apple broke the responder chain as it used to work on Mac and non-storyboard apps. I’m filing this as a bug report to find out if this indeed a bug or an “undocumented feature”. rdar://12402078

Update Oct 5th: Apple closed this as suplicate of rdar://12395544

Summary

Controls hooked up to user-defined actions on the First Responder proxy object fail to message the responder chain.

Steps to Reproduce

• Create a new Utility app
• Add a doSomething:(id)sender to the app delegate, add a breakpoint there
• in the storyboard for FlipsideViewController define doSomething: under user-defined actions
• replace the link of the Done button with one to the First Responder proxy object and choose the doSomething action
• Build&Run

Expected Results

The action should travel the responder chain and end up at the breakpoint in the app delegate

Actual Results

No action is invoked

Regression

The behavior is broken in Storyboards. It works when not using story boards.

Notes

On a non-storyboard app the sendAction of UIApplication has the next upper view controller as target. When using a storyboard the sendAction instead messages the UIBarButtonItem first. I suspect that because UIBarButtonItem is not a UIResponder subclass the default behavior is for the event bubbling to stop there.

If you add a new button to the FlipsideController and also hook this hop to the doSomething: action it doesn’t even call the application’s sendAction. On a non-storyboard app this would also normally send the action to the closest view controller.

In this special case we had a couple of rare circumstances that worked together to form a scenario where CGRectMakeWithDictionaryRepresentation partially fails to reconstitute a CGRect from a dictionary. This function is literally ancient, it exists since iOS 2 and Mac OS 10.5. This makes it even more implausible that nobody has stumbled across this before us.

In the project where we first saw the problem these where the steps that led to this bug’s discovery:

1. Create a CGRect that is not an integer
2. Write a dictionary from iOS simulator which contains a dictionary encoding this CGRect
3. Open this dictionary in Xcode’s property list editor
4. Upon saving some of the least significant digits change in the “real” items
5. This new dictionary can no longer be parsed on iOS

What’s even funnier is that some such modified values can still be read, but then the function fails internally and the remaining values don’t get parsed, i.e. stay zero.

From what I have seen researching this bug looks like certain floating point numbers cannot be represented on iOS. The normal parsing functions are able to round to the closest value that can be represented in 32-bit floats, whereas CGRectMakeWithDictionaryRepresentation fails to do so. The first value that cannot be exactly represented is truncated, all following values turn out to be Zero.

This was filed as rdar://12358120 and on OpenRadar.

CGRectMakeWithDictionaryRepresentation

Summary

CGRectMakeWithDictionaryRepresentation on iOS fails to parse certain float values from a plist saved on Mac.

This bug is a very rare occurrence because it only appears if you have non-integer values encoded in a property list, modify this on Mac (e.g. Xcode) and then try to parse it again on iOS.

Steps to Reproduce

1. on iOS: create a CGRect (123.2112731933594,123.2112731933594,123.2112731933594,123.2112731933594)
2. save it into a file, notice that the value will be 123.21127319335938 instead.
3. open it with Xcode plist editor
4. save it, the values in the file will change to be 123.2112731933594
5. load the dictionary from disk, try to extract the CGRect by CGRectMakeWithDictionaryRepresentation

Expected Results

the CGRect values should be 123.21127319335938 or 123.2112731933594

Actual Results

only origin gets a truncated value, all other values are zero: {{123.211, 0}, {0, 0}}, return value of the function is FALSE which means an error occurred.

Regression

n/a

Notes

A sample project is provided that demonstrates the issue in the form of unit tests:

• testOriginalPlist parses an iOS generated plist without issue
• testMofiedPlistByXCode parses a plist modified by Xcode showing the failure
• testParseRealString shows that the problematic representation works with float/doubleValue
• testRectMake demonstrate how modifying a fresh encoded number fails if the 5938 (iOS) is changed to 594 (Mac)

NSDictionaryCGRectParsing Sample Project

Filed as Radar #12236447 and cross-posted on OpenRadar.

Updated March 6th, 2013: “Works as Intended”

Scroll Direction setting linked for Mouse and Trackpad

Summary:

When changing the setting to reverse scroll direction for trackpad or mouse the other device’s setting is affected as well.

Steps to Reproduce:

• check the trackpad scroll direction “natural” setting
• uncheck the mouse scroll direction

Expected Results:

• the mouse setting should be separate from the trackpad setting

Actual Results:

• unchecking the mouse scroll direction checkbox also unchecks the setting for trackpad

Regression:

n/a

Notes:

This is a nuisance for people who are switching between a notebook internal trackpad and an external USB mouse with trackwheel.

The workaround at the moment is to use the AirParrot software which has no problems displaying the desktop. I filed it as rdar://12167290  and mirrored it on OpenRadar.

Update Nov 7th: Apple closed the bug report as a duplicate of rdar://11782381.

AirPlay broken if only connected display is VNC

Summary:

I have a current model MacMini that was last connected via display port and DIV to an LCD before turning it head less and putting it into my server cabinet.

When connecting via VNC to it and activating AirPlay mirroring you only see color blotches and some text fragments on the TV which is being served by a latest generation AppleTV.

Steps to Reproduce:

• disconnect any monitor to MacMini
• connect to it with VNC
• enable AirPlay

Expected Results:

• you should see the desktop mirrored via AirPlay

Actual Results:

• you only see color blotches.

Regression:

n/a

Notes:

The AppleTV is serving the TV at 720p/60 Hz. The TV is a Sharp Aquos that has a maximum of 1080i.

This feature request was filed as rdar://11767306  and on OpenRadar.

There is of course something of a workaround that we found to be working, but it relies on several techniques that might cease to work in a future iOS version.

The first step is to modify the user agent on the very first NSURLRequest that you tell the UIWebView to load.

NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:_product.productURL
        cachePolicy:NSURLRequestUseProtocolCachePolicy
        timeoutInterval:60.0];
 
// override user agent set?
if (_userAgent)
{
        [request setValue:_userAgent forHTTPHeaderField:@"User-Agent"];
}
 
[_webView loadRequest:request];

What would be fine and good but this change only holds until the first redirect or sub-request for an image or other resource. Some (but not all) of the sub-requests the web view’s delegate is asked whether they should be allowed. I found that if the original NSURLRequest is mutable then the subsequent ones are also mutable and you can imprint the custom agent there as well.

- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSMutableURLRequest *)theRequest 
    navigationType:(UIWebViewNavigationType)navigationType
{
    if ([theRequest isKindOfClass:[NSMutableURLRequest class]])
    {
        // override user agent set?
        if (_userAgent)
        {
            [theRequest setValue:_userAgent forHTTPHeaderField:@"User-Agent"];
        }
    }
 
    return YES;
}

But this only works for some sub-requests. I found in my testing that many subsequent requests don’t show here, especially if they are made from JavaScript (i.e. AJAX). That means if you are dealing with a very stubborn web platform that constantly reevaluates your user-agent then you are out of luck faking it there.

Part 2 of this workaround only works of course if the request stay mutable. The iOS docs claim that they are immutable and I believe they only become mutable if you send the original request as mutable. So this is using undocumented behavior and as such inherently unreliable.

Another – rather obscure – workaround has been documented by James Border. You can set a global user default with the “UserAgent” key.

NSDictionary *dictionary = [[NSDictionary alloc] initWithObjectsAndKeys:
   @"Your desired user agent", @"UserAgent", nil];
[[NSUserDefaults standardUserDefaults] registerDefaults:dictionary];

I was quite astonished when my attention was pointed to this. This is not documented anywhere.

So I figured it would make UIWebView much more useful if there was a native method to achieve this. Which brings me to my Radar …

Allow overriding of user-agent on UIWebView

Problem

For some use cases it is necessary to modify the user agent that UIWebView sends towards the server to get a different version of the content. Such scenarios where we needed that included opening a special version of an online shopping bag or opening the full-version of Facebook instead of the mobile one.

Suggested Solution

Expose a userAgent property on UIWebView that uses the default user-agent when nil or otherwise sends the set string. The reason why this should be a feature in the SDK is that most of the time when dealing with online hosted platform providers you have next to no chance of getting them to fix some detection mechanism that causes their platform to send the incorrect content.

To make it easier for the developer there could be some methods that would give me certain predefined user agents, like Safari for Mac, to be used with the suggested property.

Since I’m getting a knack in filing these I did the “quick file” for him, as rdar://11738458 and on OpenRadar. As always I am doing this publicly because other people out there might have experienced the same issue which can be quite nerve-wrecking. Also this problem was observed on an OS X version that is public and widely used.

Filevault2 uses incorrect keyboard layout for initial unlock

Summary:

When starting a 15″ MacBook Pro (Mid 2009) that is using Filevault2 full disk encryption the wrong keyboard layout is active for entering the initial boot password when starting the system.

Steps to Reproduce:

• on a Mac with German keyboard set system language to English, keyboard layout to German (matching the HW keyboard)
• enable Filevault2, choose a password that uses keys that are differently positioned on German and English layout. (e.g. Z and Y)
• turn off Mac
• when promoted for the hard disk password try to enter the password as it was entered with OS X running

Expected Results:

Password should be accepted in the keyboard layout used when setting it.

Actual Results:

Password is only accepted when entered with English keyboard layout.

Regression:

With Filevault 1 the password was queried later when the German layout was already active.

Notes:

This might lead to customer confusion because it misleads them to thinking that they have set their password incorrectly. Add to this the extremely stressful situation of thinking that you have lost access to all your data.

Most people would not recognize this problem because typically people would have the system language and keyboard layout be the same. But some users (especially developers and in IT) prefer to have their system in English even with a German keyboard. This also means that they will have to know where this certain characters can be found on an English keyboard to be able to successfully authenticate.

Filefault 2 apparently is using the system language layout instead of the actual HW layout or the one that is configured while running OS X.