Building an app for handloading...

As long as I'm typing... how about connectivity to the Labradar V2? And of course, as you mentioned above, Android.
I’m very happy to add more radars. The trick is getting my hands on them to figure out how their Bluetooth controls and firmware works.

For the Rangecraft, because I had one, I could connect it to my computer and poke around “under the hood.”

I’ll ask around at the next Saturday range breakfast (or range cleanup day) to see if anyone’s willing to lend me their chrono for a week.

Yeah, Android up next. I’m planning on switching - so it’s time to learn. It's just a big lift at the moment. I wish it wasn't.
 
Been following this thread and am excited, currently everything I am doing is pen and paper which is fine but not so easy to search around in as more notebooks get filled heheh
Thanks for building a better mousetrap!
 
Another quick update, the app is finally being prepped for beta/testing distribution via Test Flight for iOS. If you're not familiar with Test Flight, it's the app from Apple that lets companies and folks like me distribute an app for testing/validation (or new features) before it goes up on the App Store officially. It's a lighter weight review process and the app is free to use for Test Flight users. If you want in on the testing, dm me an email address. I'm going to start with a small cohort for a couple of reasons: a few initial testers (5-10 max) is probably a good initial gauge of what really needs changing/fixing/clarification.

I couldn't resist adding a few last minute changes, focused on a number of test plan patterns.

The (last) major update is that round-robin shot plans are now possible. Let's say you wanted to do something like the OCW testing that's regularly discussed here (and shared in this thread!). Now you can define a number of shots per charge during test plan configuration and, more importantly set the shot plan to run "round robin". This means instead of say a 3 or 5 shot group of one charge weight, you can run through a plan of 3 or 5 shots per charge weight, but going one shot-per-charge at a time and then repeating.

IMG_5791.PNGIMG_5792.PNG

The round robin mode has another trick up its sleeve pertaining to chronograph users.

Borne out of laziness, when doing round robin charge weight testing, I don't want to start and stop sessions on my chronograph. But that means I don't get useful SD/ES calculations. Starting and stopping sessions 60 times seems like a waste of time.

Even if I did, reassembling those sessions seems, uh, not fun.

So, instead, after the test plan is run, the app will download one session (or multiple consecutive sessions). It will then link up each shot appropriately, creating new sessions that properly reflect the shots for a given charge weight (or seating depths – whatever you're testing).

That means I can just dump a chrono session with say 60 shots (20 x 3 shots each) done in round-robin fashion, and still get valid shot groups with SD / ES values.

And because once in a while a chrono will miss a shot, there's even a function/button to mark shots as missed by a chrono.

IMG_5789.PNG

This new feature needs a tiny bit of testing, so I'm going to head to the range once more to make sure it's working properly. It feels like the right final feature before y'all get to try it. It allows folks to run almost any type of testing plan including round-robin plans like OCW, Cortina Method, etc. etc.

And one unnecessary polish requirement, a loading screen:

IMG_5794.PNG
 
Last edited:
What language are you programming in?
This iOS version is using Swift (v5). No cross-platform frameworks. Pure native APIs/UX. For my day job I work in Scala, which is not at all popular, but I love (particularly for the type of work I do). Scala should make the jump to Kotlin for Android-native less painful.
 
This iOS version is using Swift (v5). No cross-platform frameworks. Pure native APIs/UX. For my day job I work in Scala, which is not at all popular, but I love (particularly for the type of work I do). Scala should make the jump to Kotlin for Android-native less painful.
Ugh. Gotcha. The more I work with c++ the more I don't want to work with anything else.

What is your sales plan? You gonna get these guys to help you and then get them to pay you monthly for the rest of their lives or can people just buy once and use it?
 
It is performant, well-standardized, and runs everywhere if the programmer is careful to isolate environment-dependent things.
And it doesn't require a massive bloatware hunk of $hit IDE or RTE to compile and run. 1 file executables are a thing of beauty.
 
What is your sales plan? You gonna get these guys to help you and then get them to pay you monthly for the rest of their lives or can people just buy once and use it?
I didn't come here to start a coding holy war, there are enough "my calibre is better than yours" threads to go around. Choose the right tool for the job and also, you do you!

As for the important, and very valid question, is this going to cost anyone money, and how will that work?

The app is not backed by a SaaS cloud service, in fact, there's no telemetry in the app at all by design, so there will be no monthly fee as long as I'm the owner of the app. There is zero data mining, zero calls to external APIs (not reaching out to any cloud services, including user analytics). What you do with it is your business.

Part of that is that I'm personally sick of the wild data collection and want to do things in a way that respects everyone; but there's also a practical benefit: where I go to shoot, there's little to no cellular signal, so an app that phones home, to any home, is useless to me and, I suspect, others.

Additionally, I think it only fair that anyone here that tries out the beta, and helps in any way, can just keep using the beta/test flight versions, for free, forever. I can even make a cohort, with iOS at least, where they get the exact same version as the paid app, so they don't have to keep dogfooding development features. They will need to update/refresh once a year, but that's an Apple limitation not mine.
 
Last edited:
Great work! Your UI really looks good. I am aware of the amount of work required to develop something at this level of quality.

I also learned something in this thread; I thought scala dev were an extinct breed ;-)
 
I would love to see a data export option, ideally in an accessable format like .csv or .db. it always makes it easier to commit to trying a new tool
CSV export for everything has been there from the start. Load development plans, shot sessions, recipes. All of it. If you put it in, you can export as CSV.

(CSV import too!)
 
Why is a 'cartridge' called a 'caliber' in this app?
The two were related enough in load dev that it worked, but it's a fair point. I'll think about where the differences matter in the workflow for a bit.

Update: just poked through a few workflows and code, and you're right, just a miss on my part. Almost everywhere it says calibre it should say “Cartridge”. Under the hood every cartridge has a calibre that controls which bullets are shown (as they have a calibre field as well).

I'm working through the semantic changes now. Words matter. Thanks for pointing it out.
 
Last edited:
Wasn't trying to start a coding holy war. Just sucks to put so much time and effort into something that looks like it will turn out well only to not be able to port it for people who don't reside in the Apple galaxy within the iUniverse.

Your sales plan sounds reasonable and free use sounds like a great bennefit for the guys who help you develope the app.
 
Couple of things worth adding.

Headspace for the rifle and the case after sizing. ie. we want to set our dies to produce a couple thou of shoulder setback ... thus we need a place to record he fired case headspace as well as the sized case headspace.

Also kinda need essentially the same info for the bullet seating depth. That is we want to record the jump to the lands so we need the measured distance to the lands as well as the seating depth and thus the difference between the two - which is the jump.

A note in the powder charge field would be nice. So one could add in a couple of notes, like the max book load or what powder charge setting was used etc.




On a related note, if you ever move this kind of data into a more structured workflow instead of spreadsheets or notebooks, something like an LMS setup integrated through tools like integrate lms can actually make sense. You can centralize measurements, load notes, and batch data in a way that keeps everything searchable and consistent across sessions instead of scattered across files. Especially useful when you start comparing different rifles or long test series over time.
Yeah, I totally agree with you — keeping detailed measurements is crucial if you want consistent results. Recording headspace both before and after sizing is a great call; that shoulder setback can really affect pressures and accuracy, so having a dedicated place to track it makes adjusting dies much more precise.

Same goes for bullet jump. If you can log both the measured distance to the lands and the seating depth, you immediately know the jump and can compare loads more systematically. It saves a ton of guesswork, especially when testing different bullets or lots of powder.

I also like the idea of notes in the powder charge field. Even just small annotations like max book loads, lot numbers, or experimental tweaks make it easier to track what’s working without having to dig through old notebooks later. Honestly, a system that integrates all these measurements into one log would make load development so much less tedious.
 
Space for notes in almost any area you want to put them can be very helpful down the road, if a person takes time makes those notes. Did things go how you expected, what funky quirks did you see. I've done some charge changes at the range to account for the weather, made note of what happened when trying them, much like the benchresters do thru the course of the day. Also made notes on what I saw for penetration on kills, notes on recovered bullets when I could.
Something useful for those that shoot factory rounds or new brass in a new gun, perhaps essential with belted mags, would be to record new vs fired case dims to see how much they stretch, to see if there is a problem from the initial shot that may result in premature case separations. Sometimes it's those little seemingly silly notes that stop you from doing something 5-10-15yrs down the road, because you forgot about it. Guns get put in the safe for various reasons such as life getting in the way or newer gun is more fun, and folk may forget history on it.
 
Back
Top Bottom