Virtual Outpost

Quality is my Product — iOS is my Platform — Software is my Industry

Xcode 8 Changes #2

Sep 16

Posted by Walt Sellers in Regular Post, XCode | 2 Comments

I started updating an older project to build in Xcode 8.  I very quickly ran into these error messages:

– <Product_Name> requires a provisioning profile. Select a provisioning profile for the “Debug” build configuration in the project editor. – “Use Legacy Swift Language Version” (SWIFT_VERSION) is required to be configured correctly for targets which use Swift. Use the [Edit > Convert > To Current Swift Syntax…] menu to choose a Swift version or use the Build Settings editor to configure the build setting directly. – Code signing is required for product type ‘Application’ in SDK ‘iOS 10.0’

The center message was quickly corrected in project “Build Settings” tab by setting “Use Legacy Swift Language Version” to YES.

As I began to work on the signing and provisioning profile messages, this message began to appear:

Provisioning profile “iOS Team Provisioning Profile: <profile_name>” is Xcode managed, but signing settings require a manually managed profile.

I searched for variations on this string, but turned up nothing.  (That’s when I knew I needed to write a blog post about it.)

As it turned out, there is a release note about Xcode and manual settings:

The signing system has been rewritten to include a new mode for automatically managing signing assets, in addition to a dedicated manual mode where the profiles for the target must be explicitly selected. When automatically managing signing assets, Xcode will create signing certificates, update app IDs, and create provisioning profiles. For manual mode, only custom created profiles can be selected and Xcode will not modify or create any signing assets.
Xcode now encodes profiles in the target using the PROVISIONING_PROFILE_SPECIFIER build setting. This setting allows specifying both the team ID and the name or identifier of the profile. (23992778)

After searching and trying out different things,  I found that having the signing identity set to a specific identity instead of “Automatic” is what required the manual provisioning profile.

But in the end, a StackOverflow article gave me what I really needed:  The “General” tab of the project now has entries for signing.  If you just set them to “automatic” the signing-related problems cleared up.

Let me know if that helped you.

Xcode 8 Changes 1

Sep 15

Posted by Walt Sellers in Regular Post | No Comments

My first try using Xcode 8 at my job made me laugh a little.

I opened an older project file and it asked me if I wanted to update the Swift code.

Xcode-prompt-convert-to-current-swift-syntax?

I decided to click “Later” and worry about it a little later.  I just wanted to see what other issues would be pointed out when I tried to build.

It made my laugh when Xcode asked the same question again, but this time with the answer buttons switched around. Read the rest of this entry »

Xcode 7.x Crash when deleting Entity from Core Data

Mar 19

Posted by Walt Sellers in Regular Post | No Comments

Just a quick one:  Xcode 7.2 was crashing on me recently when I tried to delete an entity from the Core Data model.

It turned out to be some kind of issue with having the Core Data model open in another tab and set to show the graph view while deleting from the list view.

At first it was crashing when I had the list view in the main frame and graph view open in the assistant editor pane.  But it also crashed when the graph view was open in another tab.

If its crashing on you, just close the other tab or pane before deleting an entity.

Xcode 7.x Bug when Subproject has 2 Products with the Same Name

Feb 23

Posted by Walt Sellers in Regular Post | No Comments

This one looks like a bug in Xcode 7.1.1.  It was fixed in Xcode 7.2, but I’m writing it up anyway because the answer was not easy to find.

We were adding a new embedded framework to an app recently. It built on the local Mac just fine, but it failed to build on Jenkins. In fact, Jenkins kept reporting that it failed to build the sub-project’s scheme named “Mac OS X”.  But it was only intended to build the iOS scheme.

At first it seemed like a problem with Jenkins.  We could build the the project just find on Xcode on a developer’s Mac.  But then we found we could reproduce the problem by using xcodebuild in the terminal.

After a lot of aggravation, it turned out to be a problem with Xcode 7.1.x when more than one build product has the same name.  Our sub-project was set to build a framework for either Mac OS X or for iOS.  Both of them had the same name, like “myProject.framework”.

When adding a new embedded framework in the project’s “General” tab, in the “Embedded Frameworks” section with the “+” button, Xcode would see the 2 products of the subproject with the same name and nicely add “Mac” and “iOS” in gray letters.  Unfortunately, Xcode got them exactly backwards. Read the rest of this entry »

iPhone Can Fill Up with Crash Logs

Sep 8

Posted by Walt Sellers in Regular Post | No Comments

Believe it or not, the iPhone can fill with crash logs and make no more.  We recently encountered more than one person that had a crashing app, but no new crash logs were appearing.

The crash information still appears in the device console, but no crash log is created.

Syncing the iPhone with iTunes on a desktop will remove all the old crash logs, then new crash logs can be generated.

Alternatively, you can delete the old logs with Xcode if the device is local and can be connected to USB.

(And boy, has it been a long time since I published here.  I have several items I want to write up.  We will see if time allows.)

Finding Xcode’s Predefined Macros for iOS Devices (updated)

Jan 9

Posted by Walt Sellers in iOS Development, XCode | No Comments

Update to my old post: http://www.virtualoutpost.com/2012/03/11/finding-xcodes…or-ios-devices

To find the iOS predefined macros For Xcode 6, type this into the terminal:

llvm-gcc -arch armv7 -dM -E – < /dev/null | sort

(Yes, there is a single dash by itself.)
Change the -arch option to “armv6” or “armv7” or “armv7s” as needed.

 

Review: Xerox DocuMate 3220 and ExactScan for Mac

Mar 7

Posted by Walt Sellers in Regular Post | No Comments

I have a seriously large amount of old documents taking up space. To take back some space, I need to do a seriously large amount of scanning. So I decided to get a serious document scanner to do the job (in my lifetime.)

Since I had a very good experience buying a Xerox Phaser printer, I thought I would risk the extra money for a Xerox document scanner. And since I am passionate about software development, it didn’t take long for me to start writing about my impressions.  I have had the scanner for several weeks (long past the return period) so here is what I’ve found.

The Hardware:

Pluses: Read the rest of this entry »

Preventing a goto fail (part 2)

Feb 28

Posted by Walt Sellers in Interview, Regular Post, Software Development, Solid Coding, Tips | No Comments

I’ve been interviewing candidates lately, which has made me think about everyday things in terms of screening/interviewing questions. Perhaps then a good question for an iOS developer is “How would you prevent a goto-fail situation?”.

Of course, “braces” comes up first, and compiler options may come up second, so let’s change that to “Aside from braces and compiler settings, how would you prevent a goto-fail situation?”.

Over the last few days, I’ve been reversing my role to think how I would answer that from an interviewer.  The idea that occurs to me the most boils down to “defensive coding” or “best practices and standards”. Now that’s way too vague.  As an interviewer I would ask for details.  I’m sure any practiced interviewer would.

For me, the biggest problem with the goto-fail code is the assumption of success until failure throughout the instructions. In critical code, it is better to assume failure until success is specifically reached.  Read the rest of this entry »

Preventing a goto fail

Feb 25

Posted by Walt Sellers in Regular Post, Solid Coding | No Comments

There was an embarrassing coding moment in developer news recently.  When I think about how easy it is to make similar mistakes, I starting thinking like Steve Maguire in his book “Writing Solid Code”.  How could this problem have been detected or prevented? (And I’m not debating the use of GOTO’s. Someone else can do that.)

I first heard Steve Gibson describe the code on “Security Now!” podcast episode #444 (show notes). How would the compiler detect that? After I got back to a computer where I could look at it, I saw the writeup at Adam Langley’s ImperialViolet blog. Adam discussed things like how the consistent use of braces might have made it more obvious.  But Solid Coding principles stress automatic ways to detect problems, so I was happy to see Adam’s note about the -Wunreachable-code option of the Clang compiler. That might have detected code being disabled by the GOTO, but as Adam also pointed out, it is not one of the options included in -Wall option.

Adam didn’t go into what the option would reveal, so I created a quick command-line tool from templates in Xcode. Compiling with the default options failed to note the problem. Adding -Wall did not detect the problem.

But when I added -Wunreachable-code to the “Other Warning Flags”

Xcode-both-warnings-smaller

Xcode finally found the problem.  (Note that I had “Treat Warnings As Errors” set to YES.)

DeadCodeWarning4-crop-small2

 

So, adding the -Wunreachable-code compiler warning is the lesson of the day.   I’ll be looking into it for my project tomorrow.

 

 

 

Tags: , , ,

Favorite Quote 7

Oct 1

Posted by Walt Sellers in Quotes | No Comments

“It is very difficult to write simple code”  – Sang Kim

Tags: