This is a maintenance update that has performance improvements and framework updates to ensure that the app continues to run smoothly. Additionally, Speech Jammer 5.1.4 adds support for Macs using Apple Silicon (M1 Base/Pro/Max/Ultra and M2 Base/Pro/Max, as of writing). Find it in the Mac App Store.
As the migration to Swift nears completion, I will begin to assess the possibility of writing a macOS version of the app to be deployed as a native app compatible with both Intel and Apple Silicon.
This update adds new enhancements and features:
Bug fixes and performance improvements
Improvements for the latest versions of iOS and iPadOS.
Support for macOS 11 or newer (Apple Silicon required)
This update adds the ability to export individual recordings off-line for sharing without uploading to the Speech Jammer Sharing Service. This was a big step for added privacy for users. Details are available below. This update also includes enhancements for the latest versions of iOS.
This update adds new enhancements and features:
Ability to export single recordings without uploading to the Speech Jammer Sharing Service
Speech Jammer has long offered the ability to share recordings by uploading your recording (encrypted during transit) to the Speech Jammer Sharing Service, which would store your recording and make it available via a generated link. This gave enhanced compatibility by making sure the recording is shared as a standards-based MP3 file and always accessible through a highly-available service.
With this addition, users can now choose to share an individual recording without uploading it to the Speech Jammer Sharing Service. This adds an additional element of privacy for users and allows them to instantly share an Apple-codec based recording file through iMessage or any other sharing service of their choice. This will not upload any file to our servers, and will not generate any link. You can share the actual recording file.
The Speech Jammer Sharing Service remains available as an option and the choice to share offline or through the server is up to the user.
I wanted to write a quick blog post to comment on some upcoming updates to Start Usage Meter. Before I get into these changes, I wanted to circle back to my reasoning for splitting Start Usage Meter into two branches (perpetual 2.5.8.x, and 2.6 and beyond).
Why the change?
When I first started writing Start Usage Meter: I wrote it as a native Mac app and it was built from the ground up using Apple technologies. It was built to support as many older releases of OS X as possible from its birth. This meant that the app launched with OS X Lion support, even though it was released a couple of years prior to the apps development. I chose this for two reasons: (1) I felt it was important to support users on older operating systems, especially for a utility app where some users may not be able to progress past a certain OS and (2) I wanted to challenge myself to support OS X 10.7 Lion as long as possible, while still supporting the newest releases of the Mac operating system.
This was relatively easy to do for a long time. If an API didn’t exist in an older version of macOS, then I created workarounds to create the same outcome wherever possible. The only downsides were that it took some extra work and maintenance with potentially a little less polish (e.g. base localization couldn’t be supported since I cannot target OS X 10.7 and build with base localization, which meant that I needed to create separate XIB’s for each language and maintain them all separately. This meant that each language may not be pixel perfect). Where critical API’s didn’t exist, I just didn’t display it to the user (e.g. Notification Center wasn’t available in OS X 10.7 Lion, so I don’t support it and didn’t display any options relating to it).
I continuously announced my commitment to support OS X 10.7 for as long as possible and was able to keep it up for a while. I was able to work around the lack of new API’s in some cases. As long as my tools allowed me to continue, then I would.
Then Xcode 12 was released. This new version of Xcode included the new macOS Big Sur SDK’s and offered some pretty cool enhancements. The downside? You could only target OS X 10.9 or later. I had to make a decision. Do I keep the app on an old toolset, convert to a different environment, or drop OS X 10.7 and 10.8? I ultimately settled on dropping OS X 10.7 and OS X 10.8 so I can continue to build for macOS using native tools and SDK’s; however, I decided to create a second branch of Start Usage Meter: Start Usage Meter 2.5.8, which I plan to back port critical fixes and improvements from the later versions. I will always distribute 2.5.8.x as a signed and notarized app and will do this for as long as possible. This lets me finally modernize the app.
So what’s coming?
I plan to release Start Usage Meter updates shortly for the Mac App Store version. 2.6 already has some improvements that were held back due to old OS support, such as base localization and new UI improvements.
The upcoming releases will take this much further. I plan to transition Start Usage Meter entirely to Swift and modernize the codebase. There will be big UI improvements to help it feel even more like a new modern native Mac app (it is and always has been a native app, but older OS support meant holding back on some UI improvements).
The immediate upcoming changes will have some pretty impactful UI interaction improvements, which should greatly improve the user experience.
I just wanted to provide a bit of a heads up about what to expect from updates, and provide some additional clarity as to why the OS changes were made in the first place. I can’t wait to share the updates with you, and I hope it improves the experience as intended.
Note: Users running OS X 10.7 to OS X 10.8 or earlier must use Start Usage Meter 2.5.8.1, which is available from my website as an app verified by Apple and notarized. If you are running OS X 10.9 or later, then you should use the Mac App Store version as usual.
This app has native support for Apple Silicon (looking at you M1 chip!). This marks the first version of Start Usage Meter that includes a universal binary. This update also contains a few fixes to polish the app. It also includes some minor UI tweaks for macOS Big Sur.
Modernized many parts of the application to use newer macOS technologies!
Native support for Apple Silicon. The app is now a universal binary
Fixes an issue where the daily usage window would not highlight the row representing today
Note: Users running OS X 10.9 or later (including the latest versions of macOS) should use Start Usage Meter 2.6, which is available in the Mac App Store, built for the latest versions of macOS, and contains support for the newest Mac hardware
Start Usage Meter 2.5.8.1 has been released as a notarized app and is now available. It is an Intel app.
This update contains a few fixes for Start Usage Meter that have been backported from Start Usage Meter 2.6 (available on the Mac App Store for OS X 10.9 and later). This release has been checked and notarized by Apple.
SHA256 SUM (although unnecessary due to the fact that the binary is signed and notarized by Apple) Start-Usage-Meter-2.5.8.1.zip – a1129fe051bcc2c5e9dc9b5fe08ae585d2938b7e216301bfdf2de267a6b3fb60 Start Usage Meter.app/Contents/MacOS/Start Usage Meter – 1b4abd4bbde01bb9e11beaeefd04a692371ef8bd4c2b893e1cd755ac3b8f36e1
Start Usage Meter 2.5.8.1 has been released as a notarized app for OS X 10.7 or later, available exclusively through my official website. As previously mentioned and planned, this marks the first version that will not be available through the Mac App Store since version 1.5. It contains back ported improvements relevant to its current feature set. Notably, this update:
Fixes an issue where the daily usage window would not highlight the row representing today
FAQ
What’s notarization? Notarization is a feature from Apple that allows me to send my app to Apple for confirmation that it does not contain malicious content or anything that will harm your computer. It essentially offers the security advantages of a Mac App Store app, outside of the Mac App Store.
Is the app still sandboxed? Yes. Start Usage Meter 2.5.8.x is essentially the same version you’d find on the Mac App Store if I were able to continue to offer it with support for the older versions of macOS. As the app and tools evolve, I’ll need to split the app into two versions; however, the security aspects of the app remain the same (i.e. the app is sandboxed and verified by Apple). Any release outside of the Mac App Store moving forward will always be sandboxed and notarized by Apple for your security. Always make sure you download from either the Mac App Store or https://dwightd.com.
Why not just cut support? I’m really happy about my ability to continue to offer the app for all users on all operating systems. I’d like to continue that for as long as possible, and Start Usage Meter 2.5.8.1 represents my attempts to make this a reality. It contains a bug fix that is available in Start Usage Meter 2.6 on the Mac App Store. Although I may not be able to port all new features back to 2.5.8 for older operating systems, I’d really like to keep it running smoothly and issue free.
Is it still a native app? Yep! Everything about Start Usage Meter remains the same as the Mac App Store build. It is still a 100% native app written using native Apple tools and languages. It does not contain any Swift code to maintain compatibility with OS X 10.7.
Old Icon (Click to Download)
Old icon? Start Usage Meter 2.5.7 changed the icon to follow the macOS Big Sur design language. Since 2.5.8 was the last version to support OS X 10.7 and it contained the Big Sur icon, I’ve left it the same way in 2.5.8.1. That said, I have attached the 2.5.6 icon and you can copy it and paste it in the icon field by clicking the icon in the apps “Get Info” window.
Side note: the icon was slightly reduced in size in Start Usage Meter 2.6 to better match the rest of Big Sur. 2.5.8.1 contains the original, slightly larger, Big Sur icon introduced in 2.5.7.
Start Usage Meter 2.5.8 has been reviewed and approved by Apple and is now available on the Mac App Store. This version consists of Start Usage Meter 2.5.7 along with an additional fix for macOS Dark Mode.
This update, as previously mentioned, has various improvements and polishes the app. It also includes an updated UI, including the main icon that is designed for the Big Sur era. This update:
2.5.8: Addressed an issue with macOS Dark Mode
Adds a new macOS Big Sur-era icon
The daily usage window will now display an error message if the app fails to load daily usage data, giving the option to retry
Improved the daily usage window performance and reliability. This greatly reduces the energy and resource consumption that this window usually takes
Updated the main configuration user interface
Various fixes and improvements
As Mentioned Earlier This may be the last update to support operating systems before OS X Mountain Lion (or potentially more recent operating systems).
If a future update drops support for OS X Lion and/or other versions of OS X, I will upload a notarized and signed version of the app at https://dwightd.com that will be maintained and updated with back ported improvements for OS X Lion and other older versions of OS X.
As mentioned earlier, this update focusses on optimizations and improvements to various areas of the app. In addition to various improvements to existing functionality, this update adds some new features.
This update adds new enhancements and features:
Now supported on Mac’s with Apple Silicon and macOS Big Sur
Added an AirPlay button to quickly switch between headphones
New Settings section that allows you to customize certain app behaviour
Added ability to adjust Bluetooth quality and profile
Added ability to utilize built-in device earpiece, if available
Added echo cancellation feature as an option
Added ability to adjust gain/volume
Added ability to disable the delay completely
This update also:
Fixed an issue that caused the recording upload progress bar and percentage indicator to remain stuck at 0% until the upload finished
Improved the display of progress when archiving recordings
Improved reliability of the audio system
Optimized many parts of the app, which will result in a much smoother experience. This is an ongoing effort.
Improved support request system, including a much cleaner design
Fixed an issue that could cause recordings with a large file size (e.g. long recordings) to fail when sharing individually
Fixed an issue that caused the Name and Email fields to appear empty when submitting a support request
Fixed some design issues with the FAQ system
Fixed an issue that could cause shared recordings to continue playing, even when you close the recording window
Update as of August 1st 2020 at 1:57AM Eastern Thanks for your patience. This maintenance is complete and all services should be operational once again. Stay tuned for upcoming app updates very soon! Stay safe!
The shared recordings server is currently undergoing maintenance to resolve a server-side issue. During this time, some server-based functionality of the app will be unavailable (e.g. individual recording sharing).
This is to resolve a minor backend issue with recording file handling. The server is transferring files successfully and sharing properly with an encrypted connection; however, some recordings were being queued indefinitely at the first server that was chosen for the upload. This does not result in any user facing problems, but means that data is being unnecessarily duplicated. There is no security or privacy concern as the whole process is encrypted and files queued for sharing at the first server are never facing the public internet.
I would just like to fix the issue as I prepare for some big upcoming changes.
Fresh off the heels of the WWDC20 Keynote, I figured it’d be a good opportunity to provide a little bit of an update on some of the apps I currently maintain. I’ve already made a commitment earlier this year to focus on modernizing my apps codebase.
Considering the huge announcement that Apple let loose regarding the shift to Apple-based SoC’s for Mac (and the move away from the macOS/OS X 10.x naming scheme), I wanted to provide a little insight into my current plans for existing apps (which is a relatively big undertaking, albeit not as big as the one Apple has planned for their Mac lineup!)
Speech Jammer Speech Jammer 5.0 was released earlier this year after quite a bit of testing and development. It utilizes an entirely new audio engine and added a few big features to help make sharing easier. However, the focus of Speech Jammer 5.0 was modernization. For example, 5.0 moved the app to a more modern core that allows the app to utilize proper multi-tasking support. This means that users can now leave the app and continue to experience the app, even with it closed.
Speech Jammer 5.0 was just the beginning. Although there were many optimizations and many new features added in 5.0, my plan for Speech Jammer 5.x is to re-write many parts of the app for efficiency and to make sure that it’s ready for the future. The primary goal here is to move Speech Jammer entirely to Swift. Essentially, 5.x is a period of refinement.
The real work that went into Speech Jammer 5.1 is under the hood. While some components of Speech Jammer were written, or re-written at some point in Swift (namely the tongue twister feature, the FAQ system, the support system, and shared link feature), most components are still based in Objective-C. This isn’t inherently a bad thing at all, but the codebase is getting a little long in the tooth and could use some cleanup beside an overhaul, and this is a perfect opportunity to move Speech Jammer onto a modern programming language and have it better aimed for the future.
Speech Jammer 5.1 and the move to Swift Speech Jammer 5.1 is scheduled to be released very shortly some new features and reliability improvements. Notably, it adds a new options system that allows customization of many features of the app. It also allows users to use the microphone on their Bluetooth headphones (or, using the new options system, use their devices microphone for the highest quality audio). There are a lot of other options and feature requests that were implemented in this upcoming update, but we’ll discuss that in the update blog post when it’s released.
Speech Jammer 5.1 brings most parts of the app completely into the Swift world. The recordings service, sharing service, archiving service, and file management service have all been completely re-written in Swift (including the UI controller). This also brings some major efficiency improvements that can be felt throughout the app.
Speech Jammer 5.2 and beyond Speech Jammer 5.1 should be released shortly, and it brings with it a new deployment target of iOS 10 or later. It is almost entirely written in Swift (sub the main core), and lays the groundwork for the future. Speech Jammer 5.2 is also under development for release later this year, which will (hopefully) have the entire app completely moved over to Swift with a new codebase. Of course, there will be new features available with it, but the focus of this post is to provide a little bit of an update on the big transition I’ve been working on.
By moving to Swift, I can make sure that the app is ready for the future. This means I can quickly implement new features in new versions of iOS, and make sure that the app is using the fastest possible libraries.
Start Usage Meter Usage Meter for the greatest ISP ever Start Usage Meter is another project that I’ve wanted to focus a lot of my efforts on. I’ll have some more updates on it shortly; however, I’m pretty happy with where it is right now. Version 2.5.7 will be released within a few weeks containing some very minor tweaks and enhancements.
There are a lot of pieces of Start Usage Meter that use outdated or deprecated practices. For example, it doesn’t use base localization, it uses some heavier API’s, and doesn’t have a single line written in Swift. These decisions were all intentional in an effort to offer full support going back to OS X Lion. It still provides a really modern app experience on the latest operating systems, but will still run on OS X 10.7. I would still like to move it onto a more modern codebase (written in Swift) and update it, and am currently deciding the best approach. Any changes to the deprecated practices I’m currently using, will likely mean a deployment target of OS X 10.8 Mountain Lion or later.
Moving Start Usage Meter forward My current plan is to test, release, and sit on Start Usage Meter 2.5.7 to make sure it is running smoothly and without issue. At some point after its release, I am going to stamp Start Usage Meter 2.5.7 with the “battle-tested” sticker and fork it, effectively creating two separate app builds. At that time, Start Usage Meter 2.6 will be born and will be a more modern version without support for the oldest versions of macOS. It will gain all the new features which, if possible, will be ported back to the 2.5.7 version and made available through my website for those on older versions of OS X. Otherwise, 2.5.7 will receive bug fix build updates only.
I don’t have a date in mind for this yet; however, I did want to make it clear that 2.5.7 will still be available through my website as a signed, sandboxed, and notarized app. It will receive updates alongside the new versions (which may contain new features, or just back ported bug fixes). Version 2.6 and later will still be distributed through the Mac App Store and will be the best experience you can receive, so if you can run it, stay on that build path. Start Usage Meter 2.6 will also support Apple Silicon-based Mac’s natively and will also support macOS Big Sur along with the UI improvements that come with it.
Summary of plans
Speech Jammer
5.x has a goal of refinement and improvements. Building a stronger codebase for the future
5.1 will be released and will have transitioned most of the app to Swift
5.2 will have the entire app using Swift and modern API’s
5.1 and later will require iOS 10 or later (this is potentially a moving target)
I plan to support the app on Apple Silicon-based Mac’s
The goal of Speech Jammer 5.x has always been to modernize the codebase, and that work will continue through the 5.x release cycle.
Start Usage Meter
Start Usage Meter 2.5.7 to be released shortly with tweaks and enhancements
Start Usage Meter 2.5.7 (after extended testing) will branch off into a separate release cycle with support going back to OS X 10.7 Lion
Start Usage Meter 2.6 will be created and updated through the Mac App Store for more modern versions of macOS
Mac App Store version will support Apple Silicon-based Mac’s natively and macOS Big Sur UI changes
2.5.7 will receive back-ported improvements and will be distributed as a signed, notarized app on my website for versions of macOS going back to OS X 10.7 Lion.
This update includes improvements to the user interface. Specifically, this update:
Contains improvements to the Daily Usage window user interface. This includes (but is not limited to) correcting UI glitches that result in some rows appearing bold when they should not and improving spacing for better readability.
Added information text to provide clarity about the highlighted row on the Daily Usage window.
The Daily Usage window will now use the operating system’s default system font.
I hope everyone is staying safe during these trying times.
This update remains compatible with all releases of OS X from OS X Lion to macOS Catalina as of writing. I will always work to maintain compatibility with older versions of OS X for as long as I can; however, the best Start Usage Meter experience is on the latest version of macOS.
