Tag: Programming

Once again I’ve been instructed to add analytics into an app. Anyone that has ever instrumented analytics knows that it is a royal pain as analytics requires various pieces of information in all kinds of places in apps. While there are ways to mitigate the number of places that code has to be modified, someone still needs to verify that the required events are fired and the necessary parameters are included.

Like many analytics systems, Firebase batches events and sends them off to the server every so often making it hard to see in real time what events are being fired. In order to facilitate analytics verification, Firebase has a method to enable near real time events. Unfortunately this requires access to the source as the parameter Google says to add is a runtime parameter (-FIRDebugEnabled). I was also told to look at an article about debugging, but clearly the author never actually tried the method described on iOS as it references the runtime parameter which is NOT available in TestFlight builds.

Just to make sure I wasn’t crazy that there was no documented way to enable debugging in a TestFlight build, I asked a friend to review the documentation. He confirmed what I thought, but pointed out the following:

This behavior persists until you explicitly disable Debug mode by specifying the following command line argument:

-FIRDebugDisabled

Immediately after he pointed this out, I got an idea that the runtime flag stored a parameter in the UserDefaults for the app. I ran my app in the simulator using the enabled runtime flag (and another flag) and then used ControlRoom to inspect the plist containing my user defaults. I then ran it again with the disabled flag and compared the results. I found the following 2 entries when the debugging was enabled:

    <key>/google/firebase/debug_mode</key>
    <true/>
    <key>/google/measurement/debug_mode</key>
    <true/>

In order to test my theory that these 2 preferences would turn on Firebase debugging, I added a hidden preference to the app to toggle it and ran the app.

UserDefaults.standard.set(true, forKey: "/google/firebase/debug_mode")
UserDefaults.standard.set(true, forKey: "/google/measurement/debug_mode")

Once I toggled the preference, I looked at the Firebase console and didn’t notice anything. Based on the fact that the Google used runtime parameters, I thought that maybe the values were only checked at startup. So I killed the app and re-ran it. Low and behold, data started showing up in the Firebase console! I fixed up my hidden debugging setting to call exit(0) after toggling the preference, built the app and tested on a device not connected to the debugger. It worked perfectly!

I suspect that Google wanted to keep this a runtime parameter so that it wasn’t accidentally turned on in the wild and cause extra load on the servers. However, it really makes it hard to debug the analytics without access to the source code.

Just after writing this article, I searched the web again for a way to do this and found a Stack Overflow answer that sets the runtime flags when the app is started. The answers are interesting, but should also have a mechanism to turn off the debugging! To be more complete, the answers should be more like:

    #if DEBUG || STAGING
    if UserDefaults.standard.bool(forKey: "firebaseDebug") == true {
        var args = ProcessInfo.processInfo.arguments
        args.append("-FIRAnalyticsDebugEnabled")
        args.append("-FIRDebugEnabled")
        ProcessInfo.processInfo.setValue(args, forKey: "arguments")
    } else {
        var args = ProcessInfo.processInfo.arguments
        args.append("-FIRAnalyticsDebugDisabled")
        args.append("-FIRDebugDisabled")
        ProcessInfo.processInfo.setValue(args, forKey: "arguments")
    }
    #endif

Then in some hidden debug screen, add a flag to turn on firebaseDebug UserDefault.

I wrote about open source about a decade ago and how it can be good and bad. Recently I had a conversation with someone who said he wasn’t dogmatic against using open source in certain projects, but was quite cautious. I’d call this pragmatic and is what I’d like to say I am with respect to open source. In my current project, I am the sole developer working on 7 applications at once (6 iOS, 1 Mac) so my resources are quite limited. I use open source because I don’t have the time to write some code that isn’t central to the apps. However, there are other pieces such as networking, that I’ve spent the time to write from scratch so that I have full control over them.

If I was on a larger team or working on apps that couldn’t fail, i.e. health and safety, I’d be a lot more cautious about open source. If I chose to use open source, I’d make sure that every aspect of the code was reviewed and understood. For instance, just last week there was an issue with the Facebook SDK that caused apps that included it to crash. This kind of behavior should not be tolerated on apps that should not fail; my apps today aren’t going to harm anyone so while it would be inconvenient to have crashes, but wouldn’t be the end of the world.

In an ideal world, I’m not sure I’d use open source in my apps, but in the practical world, I don’t have a choice. There are definitely some great pieces of open source that exist today, but if people rely on them and don’t completely understand how they work, it will lead to failure. There are pieces of open source that are used as the fundamental building blocks of certain apps; in order to properly use them in my opinion, every developer must understand the inner workings of them so that they can debug if needed.

Auto Layout is an amazing concept for developing iOS apps as it allows for an application to more easily look good across different devices. In addition it makes using dynamic type so much easier; as someone that wears glasses I always increase the type size on my devices and when apps don’t take advantage of it, I get kind of annoyed. So when I develop apps, I try to use dynamic type and using auto layout makes things so much easier.

A common theme in apps I develop is to have a UITableView with a bunch of rows. The rows have different bits of text and the only sensible way to develop this is using auto layout. With the latest releases of iOS, a lot of code dealing with dynamic type, heights of cells, responding to device changes, etc. has been eliminated. However, there are still a few gotchas in making an app with a UITableView that behaves properly.

I’m going to go over the steps I used (and provide sample code) for how I handle this. I had a few requirements that make my implementation a little different than other tutorials on the web.

• Each cell has an image that would be at most 1/3 the width of the screen.
• The image must touch the top and bottom of the row.
• The image had to be at least a certain height.
• The image should attempt to have the aspect ratio of the original image. (Aspect Fit could leave white space; Aspect Fill could hide some of the image.)
• Images are loaded asynchronously from the Internet.
• Next to the image is up to 5 lines of text pinned to the top.
• Next to the image is 1 line of text pinned to the bottom.
• Each line of text could wrap to multiple lines.
• Increasing the type sized must resize the rows.
• The cell must have a minimum height.
• Rotating the device must work.

Writing that out sure looks more complicated than it was in my head!

I’m not going to go over the initial project setup, but will jump right into Interface Builder after I created a UITableViewCell with xib. Note that I don’t use Storyboards and opt to create a separate xib for each view controller and each cell; Storyboards tend to bite me each time I use them as I like to re-use code as much as possible and by default the Storyboard for a UITableViewController puts the cell in the Storyboard making it harder to manage. I’m sure some would argue with me that Storyboards are great, but they just don’t work for me.

1. Create a new UITableViewCell with a xib.
   
2. In the xib, add a UIImageView to the left side that is pinned to the left, top, and bottom of the cell.
3. Set the UIImageView to Aspect Fill and Clip to bounds.
4. Give the UIImageView fixed width and height constraints. (We’ll change this later.)
5. Add a vertical stack view pinned to 10 pixels from the UIImageView, pinned to 10 pixels from the top and 10 pixels from the right.
6. Add 5 UILabels to the stack view. Each label should be set for “Automatically adjusts font” and a Font of Body. Set 1 or more of the labels to have 0 Lines so that it grows vertically. Also, set auto shrink to minimum font scale of 0.5.
7. Add another vertical stack view pinned to the leading of the first stack view, 10 pixels from the right and bottom of the container and on the top to be >= 5 from the other stack view.
8. Add a UILabel to this stack view. Set the font as above.
9. Set the height constraint of the UIImageView to a priority of 250 (low).
10. Add a UIActivityIndicator that is centered on the UIImageView (set the constraints).
11. Create a UIImageView subclass that looks like this. The UIImageView uses the intrinsic size of the image in the absence of other constraints and we want more control of the height of the view.

    class ExampleImageView: UIImageView {
        var minimumHeight: CGFloat = 0
        override var intrinsicContentSize: CGSize {
            if minimumHeight == 0 {
                return super.intrinsicContentSize
            }
            return CGSize(width: 0, height: minimumHeight)
        }
    }
    

12. Change the UIImageView class to ExampleImageView.

13. Connect outlets for the 6 UILabels, the UIImageView (with the new class), the activity indicator and the height and width constraints on the UIImageView.

Your xib should look like this:

Time to move into the source of the table view cell. I’m only going to cover the interesting parts here. See my example repo at for the full example.

1. Setup a variable for the cell width. This is going to be set through the view controller so that rotation changes can change the width of the image.

   var cellWidth: CGFloat = 0 {
       didSet {
           maxImageWidth = cellWidth / 3
           setImageWidth()
       }
   }
   
   fileprivate var maxImageWidth: CGFloat = 120
   

2. Add a method for setting the image width.

   fileprivate func setImageWidth() {
       if let image = cellImageView.image {
           let scale = image.size.height / contentView.frame.size.height
           var newWidth = image.size.width / scale
           if newWidth > maxImageWidth {
               newWidth = maxImageWidth
           }
   
           contentView.layoutIfNeeded()
           let animator = UIViewPropertyAnimator.init(duration: 0.1, curve: .easeOut) {[weak self] in
               guard let self = self else {return}
               self.cellImageViewWidthLayoutConstraint.constant = newWidth
               self.contentView.layoutIfNeeded()
           }
   
           animator.startAnimation()
       }
   }
   

3. Next in the view controller, add the following to handle the change in width of the cell.

   override func willTransition(to newCollection: UITraitCollection, with coordinator: UIViewControllerTransitionCoordinator) {
       if let visibleCells = tableView.visibleCells as? [ExampleTableViewCell] {
           for cell in visibleCells {
               cell.cellWidth = tableView.frame.width
           }
       }
       super.willTransition(to: newCollection, with: coordinator)
   }
   

Believe it or not, I think that’s it! I’ve spent at least 4 weeks on this issue and keep running into some problem. Rotation and changing font sizes (Accessibility Inspector is great for testing) kept bringing up issues.

The example repo can be found here: https://github.com/sgruby/TableViewExample.

Feedback/changes are welcome! I’m sure I’m not doing something correct or there is an easier way; I just haven’t figured it out, yet.

With most software projects these days, including open source components is almost a given. There is no reason to reinvent the wheel and some components are so customized that it would take months to mimic the behavior. There are many ways to integrate these components into an application. One of my mantras when working on projects is that I just want to be able to checkout the project from a repository and build it; there shouldn’t be several steps and I shouldn’t have to worry about something outside of my control breaking the build.

Years ago when I worked on a particular project, there was a several step process to just get the source code which integrated open source components. This was extremely fragile as the references to the open source components was for an external repository that could go away at any time. When I became in charge of the project, I changed things so that we only relied on repositories that were under the control of the company (we had shared components).

In iOS development, there are now 2 (or 3) main systems for managing these external dependencies. The first is CocoaPods which is very popular, but relies on the external repositories to always be there and requires modifications to how the project is built. The newer entrant into this arena is called Carthage. Carthage gives me more control on the dependencies. The system makes it easy to store the dependencies in my repo and easily update them. In particular, I use the following command to update

carthage update --platform iOS --no-build

Basically I just let Carthage update the components and I have my project setup to do all the builds. When I checkout the project, it has everything in it and I just build. I think that this setup, at least currently, strikes the best balance to handling dependencies.

The other day I was reminded of this problem when a developer was describing dependencies on one of my projects; the developer basically said that he used a dependency management system that didn’t store the components with the source code. I’ve been writing software for awhile now and while open source makes it easier to get things done, many developers don’t consider the entire build process or risks involved in not having control over all the components.

Like most experienced iOS developers, I use an automated build system. A colleague of mine and I have spent portions of the last 2 years building up our system so what we do looks like magic to others! As part of this system, we’ve written tools and put together scripts to package our application as an .ipa (iPhone application). An .ipa file is simply a zip file with the extension changed.

Well, it isn’t that simple. It appears that how the zip is created is just as important as the structure of the package. There are various flavors of zip, libraries that do zip, and other tools that zip. In one of our tools, we were using a zip library. It appears that Apple made a change in iOS 9.0.2 or 9.1 that caused applications created by our tool to not install on devices. However, the problem was only present if the app was installed over the air or through iTunes; installed through Xcode’s Devices window succeeded. After an arduous day of debugging trying to determine the failure point (provisioning is usually to blame for failures and they can be super frustrating), I switched our tool to use the command line zip (/usr/bin/zip) and amazingly the problem went away.

It would appear that iTunes, iOS itself, and Xcode use slightly different methods for unzipping and installing applications. Since Apple’s xcrun command for packaging (PackageApplication) uses /usr/bin/zip, I think it is a safe bet. It is invoked using something like:

/usr/bin/xcrun -sdk iphoneos PackageApplication -v MyApp.app -o MyApp.ipa" --sign "iPhone Distribution: Scott Gruby"

On a side note, it also appears that there is an error in the PackageApplication script found at:

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/PackageApplication

that has:

"--resource-rules=$destApp/ResourceRules.plist");

In Mac OS X 10.10 and higher, this line is no longer valid, so if you use this command, you need to modify the script.