iOS 11 beta 1,2 - NSString sizeWithAttributes - breaking change and potential bug

Edge behavior of [NSString sizeWithAttributes] seems to be changed in iOS 11 beta 1 and 2. When asked for the

float size around 0.0;

    

    NSString *testString = @"Some test string";

    NSString *fontName = @".SFUIText-Semibold";

    

    UIFont *targetFont = [UIFont fontWithName:fontName size:size];

    

    CGSize stringUISize = [testString sizeWithAttributes:@

                           {

                           NSFontAttributeName: targetFont

                           }];

You may get very different from iOS 7- 10 values. Here is the test:

While running it on iOS 7-10, everything converges to zero string UI width:

2017-07-02 10:11:45.996 speedometer[23301:7084973] attempted font size: 1, calculated string width: 12.157471, delta: -12

2017-07-02 10:11:45.997 speedometer[23301:7084973] attempted font size: 0, calculated string width: 4.052490, delta: -4

2017-07-02 10:11:46.005 speedometer[23301:7084973] attempted font size: 0, calculated string width: 0.000000, delta: 0

 while on iOS 11 beta 1 and 2 the same test case is "stuck" on value 97 something on iPhone 6 Plus:

2017-07-02 08:29:07.157511+0200 speedometer[36517:257340] attempted font size: 4, calculated string size: 36.437256, delta: -36

2017-07-02 08:29:07.158646+0200 speedometer[36517:257340] attempted font size: 3, calculated string size: 28.340088, delta: -28

2017-07-02 08:29:07.159723+0200 speedometer[36517:257340] attempted font size: 2, calculated string size: 20.242920, delta: -20

2017-07-02 08:29:07.160738+0200 speedometer[36517:257340] attempted font size: 1, calculated string size: 12.145752, delta: -12

2017-07-02 08:29:07.161953+0200 speedometer[36517:257340] attempted font size: 0, calculated string size: 4.048584, delta: -4

2017-07-02 08:29:07.166740+0200 speedometer[36517:257340] attempted font size: 0, calculated string size: 97.166016, delta: -97

2017-07-02 08:29:07.167756+0200 speedometer[36517:257340] attempted font size: -1, calculated string size: 97.166016, delta: -97

2017-07-02 08:29:07.168736+0200 speedometer[36517:257340] attempted font size: -2, calculated string size: 97.166016, delta: -97

Looks to me as a broken "contract" and invariant. One would really expect the consistent behavior as it was since iOS7 and having the width of the string calculated as zero for zero font size and zero it should be downwards? Also string width jumping from about approaching zero values to 97.166016 when value got a bit on below zero looks inconsistent. Probably a missing unit test :)!

For me it looks like a bug and I'm reporting it to Apple now. Hopefully it will be fixed to the same consistent behavior as it used to be on iOS 7 - 10.

Defensive coding is like an alloc/release for me, I try to make it right and upfront, but doing static analysis later I found myself being "mentally away" way too often.

Yours and wishing you happy coding!

Stan.

xcode 8.3 CompileStoryboard Internal error. UICGColor encodeWithCoder. Please file a bug at bugreport.apple.com and attach ...

Was dancing with my voodoo drum for a few minutes after upgrading to xcode 8.3 today. One of my storyboards that have existed for last 3 years suddenly started to cause the compile error:

CompileStoryboard bLocNote/taxi/EditTariffStoryboard.storyboard

2017-03-30 17:48:00.332 Interface Builder Cocoa Touch Tool[29650:5173036] *** Assertion failure in -[UICGColor encodeWithCoder:], /BuildRoot/Library/Caches/com.apple.xbs/Sources/UIKit_Sim/UIKit-3600.7.47/UIColor.m:1549

2017-03-30 17:48:08.466 ibtoold[29647:5172916] [MT] IBPlatformTool: Wrote failed marshalling request diagnostics to path: /var/folders/8j/x30frbx948l8djrb6ff7mljc0000gn/T/IB-agent-diagnostics_2017-03-30_17-48-08_415000

/* com.apple.ibtool.errors */

/Users/stanislavdvoychenko/Documents/code/speedo/bLocNote/taxi/EditTariffStoryboard.storyboard: error: Internal error. Please file a bug at bugreport.apple.com and attach "/var/folders/8j/x30frbx948l8djrb6ff7mljc0000gn/T/IB-agent-diagnostics_2017-03-30_17-48-08_415000". 

Was compiling fine just an hour ago on xcode 8.2.1! Ok, it tells something on not liking the UIColor, and log it mentions further says colors should be RGB or White space. I went by "binary search" removed everything from the storyboard except the table view -> build still fails. Only value catching the eye was "Tracking" color for the section view saying showing a black stripe with no color name, I have many of these assigned in other places though, guess it is still somehow different in this storyboard, so I reselected a "black" color for it:

And it compiled! Huraaay and back to programming!

Inherited uiviewcontrollers references in one storyboard. This class is not key value coding-compliant for the key ...

I often inherit my UIViewControllers to add functionality on top of already existing. All works fine, but today I ran into the weird problem. Setup like this:



Where rangeItemEditor view controller inherits from itemEditor view controller. All outlets connected in the parent view controller. On row tap I do performSegue and then this:

This class is not key value coding-compliant for the key ...

Complaining about one of the outlets. After standard troubleshooting, checking that .destinationViewController is right, bunging my head a bit against the wall and trying [navigationController push] which worked I looked more carefully at the Storyboard ID values for these references. Here is obviously a good one:



And the other one, inherited rangeItemEditor had it empty. Filling it in and running again proved the idea that missing Storyboard ID in Identity tab for a references storyboard is a bad thing. I was not clearing this out though, not sure how it happened to be empty.

Thought I'd share to make your troubleshooting of similar cases faster!

In the end I got rid of these references in the storyboard and used [navigationController push]. Why? I just really don't want these crashes when xcode UI Editor decides to remove something behind the scenes. I've witnessed this "open the file -> get the mess" already in xcode storyboards and I really better stay safer here with using old gold manual push. Staying away from the magic until it has predictable results :).

Symbolicating bitcode crash logs in XCode

As of Xcode version 7.3 there is still a problem with symbolicating the bitcode crash logs. I've attempted several solutions, here and here, but here is what I came to:

1. Crash logs provided are for the dSYMs that Apple also provides. Just go to the iTunes connect and download them:



Once you have them right click on the crash in xcode -> "Show in finder" and copy to some target directory - that's actually a crashpoint file you are going to get.

My target directory is now ~\Desktop\crashes and here is how it looks:



Where #1 are dSYMs as copied from the iTunes connect. #2 is the crashpoint saved from the crash organizer window in xCode. #4 is a crash log extracted from the crashpoint file (right click and "show package contents")

To get #3 - a symbolicatecrash app, execute this in the target directory (xcode 7.3):

cp /Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash symbolicatecrash

For different versions of xcode the location of symbolicatecrash will be different.

To get symbolicatecrash ready to operate execute:

export DEVELOPER_DIR='/Applications/Xcode.app/Contents/Developer'

Only one step is left! That's to get your crash log symbolicated:

./symbolicatecrash a.crash dSYMs/ > a.log

And the output file a.log is looking like:

Way better, is not it?

There are nuances that I would not touch here, like these dSYM files you downloaded are for different architectures and it would be the best to match your specific crash log to a corresponding dSYM. I'll leave this detail to you, my experience is that function names do match quite well, then it is just about the line of code information you'll be getting. In above picture, given crash and dSYM are matched well, you can see the line of code where the crash exactly happened. Otherwise you'd see +xyz there and that's not that helpful.

This is it. Please don't judge me strictly, I'm not an expert in any field, as I learnt over time :)! Knowing more than I do? Share your knowledge in the comments!

Yours,
Stan.

xcode - Configure for analyzing. The scheme is not configured for analyzing.

I'm used to run analyzing cycle on my apps when moving closer to their public release. This time xcode (7.3 (7D175)) greeted me with:

"Edit the scheme to enable analyzing, or cancel the action." with that "Edit Scheme ..." was not opening anything and I didn't notice anything extra in the schema editor to enable analyzing.

I even created a clean new project to see if error would be present there as well, and it was.

So after scratching my head a bit I just set a RUN_CLANG_STATIC_ANALYZER as true for the target/build where I needed it:

This way I got the static analysis messages back.

Hope this can help someone!

Update. Or as Jaime Santana commented, just "launch Analysis from the menu option Menu -> Product -> Analyze". Thank you Jamie, that worked!

Xcode 4.3.1. - new features that I like

By far 4.3.1. is my favorite Xcode release :) A lot of those tiny details that disturbed me are gone! Here is my short list.

1. When you create a new group, now you can edit its name in place.

2. Now when creating an objective-c class it creates a private intefrace for you. That is a cool thing for me as I was often too lazy to do it myself (shame, I know)

4. It marked now as warning all those places where I forgot to call [super dealloc]. My fault, but very nice from Xcode as it helped me to find few leaks I was hunting for some time now.

5. Installation experience. Installed from the appstore with no single issue, offered to remove older versions and had no single issue with existing projects. I was afraid of burning the night oil again, but not this time! Oh, thanks.

6. No crash since installing. I was used to Xcode crashing 2-3 times every evening. Great time saving again.

7. Last but not least! I've been using lldb for some time now, but was always running into "Invalid service" etc kind of problems when I even had to restart a device and Xcode from time to time. Since I've installed 4.3.1 NO SINGLE CASE when I had to do this! Saves me really an hour a week at least :).

I guess real list will be much longer. It is just what I ran into during the first few days.

On GPX files for Xcode 4.2

I totally enjoy the new location testing features of xcode 4.2. Ability to test with any fake location is really a blessing! Today I saw that the app is not working right in one of the locations (it works poorly in few of them, but I’m fixing intensively :)). That was South Brisbane, and my first chance to add a custom location.
After thinking for a while what would be the minimum data for a file required I actually found out that Xcode is capable of adding a minimalistic template for a start!:

That is what a file looks like:

<?xml version="1.0"?>

<gpx version="1.1" creator="Xcode"> 

    <wpt lat="49.930008" lon="15.369873">

         <name>South Brisbane, AU</name>

    </wpt>

</gpx>

Name the file nicely as its name is used when you pick it up:


To see how to add speed, accuracy, etc to your testing/simulation you may continue with: Use Automation to bring speed, accuracy, altutude, etc to your location app testing

Links:
GPX specification: http://www.topografix.com/gpx.asp
Google Maps 2 GPX: http://www.elsewhere.org/journal/gmaptogpx/

XCode 4–svn. Could not authenticate to server: rejected Basic challenge

Yeah, why this should happen to me during my 1am attempt to check in changes back? I upgraded today to XCode 4 and everything seemed to work ok with svn until this moment. Based onto error message detail and some info here: http://help.beanstalkapp.com/discussions/problems/3083-cannot-connect-with-xcode-4-dev-preview one can say xcode is not sending my credentials to svn right.

I’m not sure what was the version of svn before upgrade on my mac, now it shows on svn –version: svn, version 1.6.5 (r38866). After several attempts to put my login info to the “repositories” place, I had a blast from the past. Ok, so probably this info is cached inside svn itself and after upgrade today it got wiped out?. I have anonymous read access enabled, so that would explain my checkouts working just fine.

So lets use svn itself to attemt to solve this:

cd to your working folder (where your xcode project is located)

use svn st to list your changes inside working folder

use svn commit to commit your changes.

Here, the moment comes and dialog looks like:

1. Stanislav-Dvoychenkos-MacBook-Pro: projectfolder stanislavdvoychenko$ svn commit -m"commit after xcode4 upgrade"
2. Authentication realm: <http://192.168.1.181:80> Subversion Repository
3. Password for 'stanislavdvoychenko':
4. Authentication realm: <http://192.168.1.181:80> Subversion Repository
5. Username: Enter Your username here
6. Password for 'Your username': Enter Your password here

On line #3 just do enter, it will come to #5 eventually if there is no your “computer user” in svn. And on #5 and #6 comes your chance to input correct svn user name and password.

After this procedure, xcode 4 started to commit just ok as well. Argggh, now running to bed!