What's New in Bug Trackr 3.0.2

Bug Trackr 3.0.2 is now available on the App Store. While this update includes some important bug fixes, it also includes a new sync progress bar.

Located in settings, the sync status bar will appear while a sync session is in progress. It's a small addition but handy when you want to know what's happening behind the scenes.

(Speaking of behind the scenes, this version includes a few more classes rewritten in Swift. While Bug Trackr was already about 10% Swift code, new features and areas of the app that require significant change will be written entirely in Swift.)

What's New in Bug Trackr 3

Bug Trackr 3 is now available on the App Store!

Version 3 is a major milestone for Bug Trackr with great new features like sync, Dark Mode, a modern UI, support for iOS 10 and the latest devices, a new icon, widget, and more.

Sync is the most requested feature to date and it’s finally available for all Bug Trackr users! Bug reports and apps are synced between your devices via iCloud. There is no setup to do, it works out of the box. Simply sign into iCloud and enable iCloud Drive on your devices.

This update centres around consistency. Every aspect of the UI was rebuilt from the ground up. But it’s more than the way it looks; text throughout the app now responds to user font preferences, iPhone 6 and 7 Plus users can enjoy using the app in landscape split view mode, and Quick Actions on iPhones with 3D touch allows users to jump right into the content that matters most. Bug Trackr 3 is a modern app built for iOS 10 both on the surface and under the hood. It takes advantage of the latest Apple technologies to ensure it’s fast and reliable.

Another popular feature request is Dark Mode. With Dark Mode enabled, the entire interface dynamically changes to a darker themed UI that’s easy on the eyes and great when working at night or in darker environments. It’s available exclusively for Bug Trackr Premium subscribers.

Bug Trackr 3 greatly improves the app import process. Now, for iOS and macOS apps, after selecting an app platform and entering an app name, Bug Trackr will search the App Store for matches as you type. Also improved is the new Bug Report Screenshot Viewer that displays the size and dimensions of your screenshots. Lastly, bug report and app info layouts have been redesigned to better focus on their content.

Bug Trackr 3 is ad-supported and introduces the Premium Subscription. With a subscription to Bug Trackr Premium, you’ll have access to Dark Mode and you won’t see any ads. Subscribers will also be directly funding future development of the app. Users who have purchased the Bug Trackr Pro in-app purchase in previous version can enjoy complimentary access to all premium features until December 31, 2017.

I hope you’ll enjoy Bug Trackr 3 as much as I do. I’d like to thank all of our beta testers for their hard work, really appreciate it!

For the latest news about the app and future betas, follow Bug Trackr on Twitter @bugtrackrapp

Learn more about Bug Trackr

Bug Trackr on the App Store

What's New in Screenshot++ 2.4

Screenshot++ and Screenshot Sweeper have both been updated for iOS 10, iPhone 7, and iPhone 7 Plus!

Screenshot++ 2.4 also includes a redesigned Widget that feels right at home on iOS 10.

Grab the free updates from the App Store!

Ps. As a sneak peek, Bug Trackr 3.0 is well into development with fantastic new features I can't wait to share with you! Stay tuned.

Developing for iOS 9: Supporting Dynamic Type and Responding to User Changes

Dynamic Type was introduced with iOS 7 as a way for developers to abstract font details like typeface, size, weight, and kerning into a series of pre-defined font categories called Text Styles. 

In this post, you'll learn how to support Dynamic Type in your app including how to properly respond to user text size changes.

May 2016 News

I've just finished work on Screenshot++ 2.3 and Screenshot Sweeper 1.2. Both of these updates include enhancements to VoiceOver and Accessibility, keyboard shortcuts, and a refreshed UI.

Screenshot++ 2.3 is a sizeable update and includes a slew new features that I think you'll love. More info to come when the 2.3 update launches on May 12th. A big thank you to my wonderful beta testers for their hard work over the last 2 month for making it a great release!

My plan is to return to working on iSource 3. It's a massive new app/update that has taken a considerable amount of work. While it's been delayed past this school year, it'll be worth the wait. It's on schedule to release before the new school year in September. The first iSource 3 beta will be available in June and I'm looking for students and testers who are interested in testing and providing feedback. If this sounds like you, please get in touch!

- Wes Dyson

Developing for CloudKit - Part 4

Read Part 1 in series on Developing for CloudKit

Read Part 2 in series on Developing for CloudKit

Read Part 3 in series on Developing for CloudKit

In the first 3 parts of Developing for CloudKit, I walk through creating a sync layer for Core Data that uses CloudKit as its backend.

I mentioned at the end of part 3 that I wanted to “abstract the sync layer so it's independent of your data model. I hope to open source it at some point in 2015”.

In the past year, I improved and made many changes to the sync layer (called SSCloudManager) and it shipped as the syncing mechanism in Screenshot++.

The main issue is SSCloudManager is still tightly coupled to the Screenshot++ data model. Creating a version of SSCloudManager that’s data model agnostic would require substantial time to invest that I simply do not have. Because of that, I began searching for a SSCloudManager replacement that didn’t involve months of my time that I would rather spend elsewhere.

Currently, I’m using Ensembles 2 as a replacement for SSCloudManager in development of a few projects. It’s everything I envisioned SSCloudManager to be and then some. I love it.

I’ll be posting in future about adopting Ensembles 2 into my projects. In the mean time, if you’ve created your own sync layer, I would love to hear about it.

Sunset for Parse

Allen Pike’s piece on the Parse shutdown is insightful, in-depth, and a great read. Marco’s response adds his thoughtful perspective.

In early 2013, I began looking for a syncing service to use in multiple iOS apps. I was one in a long list of developers who viewed sync as an add on, that sync should be as easy as adding another project dependancy. Parse added much of the functionality I was looking for. It was easy, cheap, and the company seemed to understand the needs of their customers.

It wasn’t long after I began testing Parse integration in a sample project that news broke of the Facebook acquisition. Parse promised that with Facebook’s backing, Parse would be able to grow faster and not worry about monetization. All in the name of good will for developers.

While I applauded their enthusiasm, the acquisition meant that from that day forward, Parse would be acting in Facebook’s best interests, leaving developers in second place.

Because I have zero faith in Facebook, I could not have faith in Parse as a product or a company and began exploring alternatives.

That decision paid off this week. Instead of scrambling to figure out a new backend as a service (BaaS) and migration strategy, I can instead use that time and effort to continue building new apps and making improvements to existing products.

The Parse shutdown has brought the BaaS debate back to the forefront in the developer community. That is, should developers roll their own BaaS or migrate to a Parse alternative like CloudKit?

Instead of relying on Parse, I jumped into Apple’s CloudKit over a year ago. It’s baked into Apple’s platforms and (for now) has Apple’s support. I use CloudKit as a back-end for Screenshot++ and in unannounced projects.

Allen and Marco lay out the two sides of this debate quite well. For many developers who have experience in running their own servers, this has always an easy decision. Experienced backend developers like Marco haven’t had to rely on 3rd party solutions. For them, it’s relatively easy to roll their own solution and today they’re in the clear; it’s hard not to hear the smug comments coming from atop their high horses.

For the rest of us, Parse was the solution to a problem that few app developers have the experience or resources to properly solve. I don’t view Parse as a shortcut and I don’t think the objective should be to rely on a service like Parse until you can create something better in-house.

For the 600,000 apps that used Parse, they’re in a tight spot and most of those will end up abandonware if they’re not already. To insinuate their developers should have all created custom backends is out of touch with today’s App Store economic reality.

With Parse out of the picture and the app BaaS market underserved, now is the perfect time for a new competitor to fill the void.