Robin Winters: fitness technology

Verify a Swift package’s minimum toolchain and CLI contract

Robin Winters — Sun, 04 Oct 2026 03:45:00 GMT

Verify a Swift package’s minimum toolchain and CLI contract

Robin Winters · October 3, 2026

I’m an iOS / Full Stack Engineer at ShowFlex, a shipped iPhone fitness product. This article examines a separate, public Swift teaching package prepared with coding-assistant support. Its fixtures are synthetic; the results below are not a test report for ShowFlex.

A package that passes on my current Mac has established something useful. It has not established that another person can build it on the oldest supported tools, on Linux, or with an unexpected command-line input. Those are different questions, and each needs a concrete check.

The fitness event data pipeline declares Swift tools version 6.0 and provides a library plus a normalize-events executable. The example turns synthetic event records into normalized events and decision receipts. Release 0.1.1 adds compatibility evidence without changing the library, executable source, tests or fixtures from 0.1.0.

Record what actually ran

The manifest’s Swift tools version specifies a minimum tools requirement. It is a declaration, rather than evidence that this package was executed with those tools.

The public workflow run records three successful environments:

Environment	Observed compiler	Checks
Linux, official Swift container	Swift 6.0.3	12 unit tests and an exact fixture-output comparison
macOS 15 runner	Apple Swift 6.1.2	12 unit tests and four CLI contract cases
Ubuntu 24.04 runner	Swift 6.4	12 unit tests and four CLI contract cases

These are the same 12 unit tests executed in three environments. They are not 36 distinct tests. Swift 6.0.3 supplies evidence for a specific compiler in the declared 6.0 line; it does not prove an execution on 6.0.0. The package’s iOS deployment declaration likewise does not establish an iPhone runtime result.

Each job prints swift --version before building. Runner labels alone are too imprecise for the compatibility record: the compiler observed on a hosted runner can change.

Test the executable boundary separately

Library tests can pass while the executable’s exit status, output stream or input decoding is wrong. The host-runner jobs invoke Scripts/check-fixture.py, which checks four cases:

The complete synthetic fixture succeeds, writes no error, and produces the expected normalized events and receipts.
An empty array succeeds with empty events and receipts.
Malformed JSON exits with status 1, emits no success report, and writes the specified input-contract error to stderr.
An object in place of the expected array produces the same rejection behavior.

The fixture assertion compares the complete decoded JSON document. Checking only the event count would miss changes to identities, timestamps or conflict receipts. The rejection checks inspect stdout as well as stderr: an error message is insufficient if the process also emits an apparently successful report.

The Swift 6.0.3 job runs a narrower check: it executes the valid fixture and uses diff against the expected output file. It does not run the other three CLI cases. Keeping that distinction visible makes the evidence easier to trust.

Reproduce the release checks

On a machine with Git, Swift and Python 3, check out the published tag:

git clone https://github.com/RobinWinters/fitness-event-data-pipeline.git
cd fitness-event-data-pipeline
git checkout 0.1.1
swift --version
swift build
swift test
python3 Scripts/check-fixture.py

The Python script uses the standard library. Its four-case check expects the debug executable produced by the preceding build. The versioned compatibility record distinguishes these host checks from the container’s narrower comparison.

State the remaining gaps

The workflow uses read-only repository permissions, a pinned checkout action and a pinned minimum-toolchain container. It needs no private application credentials. Those choices make this small public example reproducible without connecting it to a production backend.

The checks establish the recorded package behavior in the recorded environments. They do not establish physical-device execution, private product behavior, performance under real event feeds, or automatic compatibility with every later compiler. A useful next compatibility check should answer one of those unresolved questions, rather than add another badge for the same run.

For native product work, the habit carries over: distinguish an API declaration, a successful build, a tested boundary and an observed user interaction. Each is valuable; each supports a different claim.

Robin Winters works on Swift, SwiftUI, MapKit and Firebase at ShowFlex. Professional reference · robin.ac. This self-authored technical account was prepared with editorial and coding-assistant support.

ShowFlex: event discovery connects native interaction with structured data

Robin Winters

ShowFlex: event discovery connects native interaction with structured data

Robin Winters — iOS/Full Stack Engineer, 2024–present

I’m an iOS / Full Stack Engineer at ShowFlex, a shipped iPhone fitness product available on the App Store. Since 2024, my work has spanned Swift and SwiftUI engineering, mobile architecture, MapKit event discovery, Firebase-backed data, interaction quality and release execution. Here is how native interaction and structured event data meet in that work.

A map is one part of a discovery flow

Event discovery connects a user's query, active filters, a set of locations and the event currently being inspected. Search results and map markers should refer to the same event identities. A detail sheet should describe the selected event even when the surrounding result order changes.

My work includes MapKit, search and filtering, dynamic geocoding, draggable detail sheets and persistent navigation. The product problem crosses those components: the interface needs clear state transitions as data and selection change. Accessibility, motion and efficient loading are part of the approved engineering scope.

The companion Swift search example demonstrates one general state-management problem: rejecting asynchronous results that belong to an older query. It is a separate educational package, not extracted ShowFlex code and not evidence of the exact implementation shipped in the app.

Event information needs a usable structure

The approved data work includes ingestion pipelines that normalize global event calendars, athlete metadata, registration information and media into structured JSON and Firebase-backed product data. Source information and native presentation meet at that boundary.

A calendar entry, location and registration link are useful only when they can be connected to the event a person is viewing. This explains why the work spans both data handling and the consumer interface. No throughput, latency, accuracy or adoption figures are claimed here.

Public release evidence

The ShowFlex iPhone App Store listing, checked October 2, 2026, identifies ShowFlex Inc. as developer and seller. Version 17.0 describes an interactive IFBB events map and calendar import tools for IFBB Pro and NPC events. That is public evidence for an iPhone product and the listed map/calendar release.

It does not establish an Android release, individual authorship of every feature, a measured business outcome or release of the AI prototypes below. Store metadata can change; the check date matters.

Applied AI remains a distinct work stream

My approved scope also includes prototypes for AI-assisted physique and posing feedback and predictive competition features. These are experimental workflows. They are not described as released product capabilities or validated fitness assessments.

The distinction matters when assessing the portfolio: released iPhone event discovery has public product evidence; AI prototype work has a narrower professional claim and needs additional releasable demonstrations before it can become a detailed implementation case study.

Existing work account · ShowFlex · Portfolio · Professional profile

Updated October 2, 2026. Self-authored professional account prepared with editorial assistance.

Distributed Kinematic Sensing and Exercise Intelligence Across Apple Fitness+, GymKit and HealthKit

Robin Winters — 2026-07-18

Distributed Kinematic Sensing and Exercise Intelligence Across Apple Fitness+, GymKit and HealthKit

By Robin Winters

First published July 18, 2026 on LinkedIn. Republished October 2, 2026 with original wording, images and captions. Technical observations and opinions retain their original context.

Really need to work on the title.

By combining motion data from Apple Watch, AirPods, iPhone and connected gym equipment, Apple devs could make strength training as measurable as running or cycling.

I've been a professional/competitive Bodybuilder for well over a decade now, and I'm constantly amazed at how difficult it is to find a more modern way of tracking my workouts. The vast majority of the fitness tracking ecosystem is primarily geared towards activities that involve some variation of a pedometer and a heart rate monitor. This works great for running or cycling, especially when you throw in a GPS tracker. However, the "Traditional Strength Training" side of fitness tracking is still primarily done manually in some form of zhuzhed up spreadsheet.

Don't get me wrong, I'm a big fan of spreadsheets. The internet itself is nothing more than an array of spreadsheets connected by a series of tubes, but I think we can do better than Lotus 1-2-3 in 2026.

What I'm proposing is basically a form of motion sensor triangulation across AirPods, Apple Watch, and iPhone, tied into GymKit, Fitness+, and HealthKit, sprinkled with Apple Intelligence framework to track and log movements commonly associated with "traditional strength training" aka Bodybuilding, so I don't have to log sets and reps simultaneously during my already demanding workouts.

By coordinating Apple Watch, motion capable AirPods and iPhone, supplementing them with workout programming and connected equipment, we can construct a body area sensing system capable of recognizing exercises, detecting sets, counting repetitions and relating mechanical work to physiological response.

Dumbbell Front Squat, for the curious.

Distributed Sensing

The concept can be described as distributed kinematic sensing; several devices observe different portions of the body and contribute those observations to a shared movement model.

Apple Watch provides the clearest view of the hand and arm. Its accelerometer and gyroscope can measure wrist acceleration, rotation, orientation and repetition cadence. For curls, lateral raises, rows and presses, the wrist trajectory frequently contains enough information to identify repetition phases and estimate tempo.

The Watch also supplies physiological measurements such as heart rate and heart-rate recovery. It can therefore connect a movement with the body’s response to it.

AirPods provide a second anatomical reference point. Their motion sensors observe head orientation and movement, helping establish whether the user is standing, seated, hinged forward or lying down. This may help distinguish a standing shoulder press from a bench press, a seated curl from a standing curl or deliberate exercise from unrelated wrist movement.

AirPods Pro 3 make this role more interesting. Apple now sends AirPods heartrate and motion data to the iPhone during workouts. When AirPods Pro 3 and Apple Watch are worn together, Apple uses multiple heartrate streams and automatically selects the source with the highest confidence at that moment. Apple’s AirPods workout documentation

Collect overlapping measurements, estimate confidence and use the most reliable source for the current moment.

The iPhone could contribute in two distinct modes. When carried securely in a pocket, it becomes a sensor near the pelvis, making it useful for squats, lunges, deadlifts and step-ups. When positioned to observe the user, its camera could provide whole-body pose estimation, range-of-motion analysis and basic symmetry feedback.

An iPhone resting in a gym bag would contribute nothing. The system would need to determine whether the phone was operating in pocket mode, camera coach mode or not participating.

Apple already exposes much of the necessary plumbing through Core Motion, AirPods motion APIs and mirrored Watch–iPhone workout sessions.

When I move you move, just like that?

Fitness+ has an enormous advantage

Automatic exercise recognition in an open gym is difficult because many movements look similar when observed from one point on the body. Reaching for a water bottle can resemble part of a curl. A front raise can resemble a shoulder press. A barbell squat may produce very little wrist movement.

Fitness+ changes the problem because the workout already has a script. During a Fitness+ session, Apple knows which exercise the trainer is demonstrating, when the interval begins, how long it should last and approximately how many repetitions are expected. It also knows whether the user should be standing, seated, supine or hinged.

The system no longer needs to ask, “Which of hundreds of exercises is this?” It can ask, “Is the user currently performing the expected squat, and where are the repetition boundaries?”

This prior knowledge should make recognition substantially more reliable. It could support live observations such as:

“Rep 8 of 12”
“Two repetitions behind the trainer”
“Your range of motion shortened during the last three reps”
“Your eccentric phase is faster than the previous set”
“Your heart rate recovered 18 beats during this rest period”

The experience should remain confidence aware. A low confidence estimate should not be presented as indisputable fact. Fitness+ could display a tentative count or defer confirmation until the rest period.

The Open Gym version

Outside Fitness+, the system could use a progressively assisted workflow.

A user might begin by selecting a saved routine or naming an exercise with Siri. Once the exercise is known, Apple Watch could detect the beginning and end of each set, count repetitions and measure tempo automatically.

If no exercise was selected, the system could propose one after observing the movement:

“Looks like 10 incline dumbbell curls. Correct?”

High confidence sets could be committed automatically. Low confidence detections could remain suggestions. Correcting an exercise would provide an individualized calibration signal, allowing the system to learn the user’s preferred movements, wrist placement and equipment.

A practical processing pipeline would contain several stages:

Activity segmentation: Separate exercise from walking, equipment setup and rest.
Posture inference: Use head, wrist and pelvis orientation to estimate body position.
Exercise classification: Compare the observed movement with the routine, Fitness+ timeline and trained exercise library.
Rep phase detection: Identify concentric, transition and eccentric phases.
Confidence estimation: Decide whether to save, suggest or request confirmation.
Physiological association: Relate each set to heart rate, recovery and perceived effort.

On device processing would allow raw motion and camera data to remain local. Only the derived workout record would need to enter HealthKit.

This is already an active product category

Automatic strength tracking is not an untouched field. Several companies already offer parts of the proposed experience.

Sonar Fit uses Apple Watch or AirPods Pro motion sensors to count repetitions, detect sets and begin rest timers. It specifically describes using AirPods for head motion tracking and permits users to train with the Watch, AirPods or both.

HealthBuddy also uses an on device movement model that reads accelerometer and gyroscope data from AirPods and Apple Watch. It performs live rep counting and connects with Apple Health.

Neither product publicly explains whether Watch and AirPods data are combined into one confidence weighted movement model or primarily operate as alternative input sources. Neither presents the wider Fitness+, GymKit, standardized strength data and Vitals architecture proposed here.

Train Fitness demonstrates how far wrist only recognition has progressed. The company claims automatic detection of more than 470 exercises, along with rep, acceleration, velocity and tempo tracking using smartwatch movement.

Garmin has offered automatic rep counting, set detection and exercise identification in its Strength profile for years. Its own documentation acknowledges the need for users to correct counts when necessary. Garmin’s rep-counting documentation

WHOOP has approached the problem from another direction. Its Strength Trainer uses inertial motion, biomechanics and cardiovascular data to estimate muscular load and incorporate it into Strain and Recovery. For the most precise calculation, users enter exercises, sets, repetitions and weight; its hands-off mode estimates muscular demand from movement profiles and heart rate. WHOOP’s Strength Trainer research

Connected gyms such as Tonal and Tempo solve the sensing problem by controlling the environment. Tonal measures cable displacement and resistance while tracking pace, range, symmetry and repetitions; Tonal 2 adds camera-based analysis. Tempo uses iPhone based computer vision and recognizable weights to provide rep counting and guidance. These systems can produce richer measurements, but only within their respective equipment ecosystems. Tonal’s coaching system, Tempo’s iPhone-based system

The market has therefore produced many of the pieces. What it has not produced is a shared platform that makes those pieces interoperable.

Google has patented the earbud-plus-watch concept

Google’s patent portfolio contains a particularly relevant example.

Its system receives motion data from two wearable devices, explicitly suggesting that the first may be an earbud and the second a smartwatch. Multiple inertial streams are processed to determine exercise types and repetitions. The European patent was granted in March 2025 and is currently listed as active. Google’s exercise-recognition patent

This is strong evidence that distributed ear/wrist exercise recognition has been considered at a serious engineering level.

It also means that combining earbud and smartwatch IMUs should not be characterized as an entirely new invention. The more differentiated question is how Apple could turn distributed sensing into a coherent platform experience.

Apple has contemplated much of the larger system

Apple’s own pending patent application, “Detecting and Tracking a Workout Using Sensors,” was published in March 2025.

It describes a system capable of:

Identifying specific strength exercises
Counting repetitions and sets
Detecting incomplete repetitions
Combining computer vision with smartwatch IMU data
Receiving data from smartphones, heart-rate monitors and external sensors
Detecting work and rest periods
Adjusting rest guidance using heart rate or respiration
Identifying weights through computer vision and OCR
Receiving equipment data through RFID, NFC, Bluetooth or Wi-Fi
Detecting selector-pin positions and calculating barbell plate loads

The application is heavily oriented toward a head mounted spatial computing device (can't image what that might be /s) but its supporting sensor network closely resembles the broader architecture considered here. Apple’s workout-tracking patent

A patent does not guarantee that a product will ship. It does, however, demonstrate that Apple has considered automatic strength recognition, rep counting, weight identification and cross-device sensing in a unified system.

How is the phone staying connected to her hip?

What the research says

Researchers have studied exercise recognition and repetition counting from wearable inertial sensors for more than a decade. Results can be impressive for movements that produce distinct trajectories, but accuracy varies significantly by exercise and sensor location.

One study evaluated sensors worn at the chest, upper arm, wrist and ear. The chest-mounted sensor performed best, while the ear-mounted sensor performed worst by itself. ExerSense study

That supports a "Division of responsibility". AirPods should normally serve as contextual evidence rather than the universal primary rep counter. Their value lies in helping the system understand posture and body motion when Apple Watch sees only the wrist.

Other Apple Watch research has achieved promising exercise recognition and repetition counting results, although bench press has proven more difficult than squats or deadlifts in some evaluations. Smartwatch strength-training validation study

No individual sensor should be expected to understand every exercise. The benefit of distributed sensing is that the system can degrade gracefully:

A curl may be counted primarily by the Watch.
A squat may rely more heavily on the pocketed iPhone.
A bench press may combine Watch motion with AirPods posture.
A camera-enabled session may override uncertain inertial estimates with pose information.
A connected machine may directly report movement and resistance.

The resistance problem

One measurement remains difficult to infer from body motion alone: the actual weight being lifted.

A slow repetition could indicate a heavy load, intentional tempo, accumulated fatigue or an inexperienced lifter. None of those possibilities can be distinguished reliably from rep velocity alone.

Resistance must therefore come from another source:

User input
A remembered previous load with quick confirmation
Computer vision reading a dumbbell, plate or selector stack
NFC or QR identification
A connected cable machine, rack or smart weight
A strength-oriented extension of GymKit

Apple’s patent explicitly discusses visual weight recognition, selector pins, RFID, NFC and wireless equipment communication. That validates the importance of the equipment layer. I personally think that NFC and QR/RFID weights would be a huge step in the right direction, and would be fairly trivial to implement; NFC stickers applied to free weights or plate loaded machines, etc etc.

A future GymKit for strength equipment could communicate:

Equipment and exercise identity
Selected resistance
Cable or lever displacement
Rep velocity
Range of motion
Left/right force or displacement
Seat and handle configuration
Weight changes during drop sets

HealthKit needs a strength training data model

HealthKit recognizes traditionalStrengthTraining as an activity type for machine and free-weight exercise. It also permits custom metadata to be associated with workouts. But it does not currently offer a standardized, interoperable schema for strength training structure.

An application can record sets and reps through custom metadata, but another application may not understand what those fields mean. HealthKit workout metadata demonstrates both the available foundation and the limitation.

A native strength representation should be hierarchical:

Workout → Exercise → Set → Repetition

An exercise record could contain:

Exercise identity and variation
Equipment
Primary movement pattern
Targeted muscle groups
Confidence and provenance

A set could contain:

Resistance
Repetitions
Set type
Duration
Rest interval
Perceived effort

Individual repetitions could optionally include:

Concentric and eccentric duration
Range of motion
Velocity
Completion quality
Sensor confidence

This would allow Fitness+, third party workout apps, connected gym equipment and coaching platforms to exchange strength data rather than reducing an entire session to duration and calories.

Connecting mechanical work to Vitals

The Vitals app is primarily based on overnight measurements such as heart rate, respiratory rate, wrist temperature and sleep duration. Those signals should not be used to detect repetitions. Their value is as recovery context. Apple’s Vitals documentation

The more useful relationship is:

Overnight baseline → planned workout → measured sets and resistance → effort score → recovery trend

HealthKit already supports perceived and estimated workout effort, while Apple’s training-load system compares recent workout intensity and duration with longer term activity. HealthKit effort support

Duration alone is an incomplete description of strength training. Fortyfive minutes might contain a light circuit, a heavy squat session or more conversation than lifting.

A record of 14 working sets, 8,200 pounds of total volume and declining concentric velocity provides much richer context. It would help training load reflect the work performed rather than merely how long the workout app remained active.

WHOOP’s muscular load model demonstrates demand for precisely this connection. Apple could go further by combining mechanical records, workout effort and overnight trends within HealthKit.

A realistic product roadmap

The strongest first gen product would begin with Apple Watch and a known workout plan. Fitness+ sessions, saved routines and user-selected exercises would provide the expected movement. The Watch would detect repetition timing. AirPods would help establish posture. The iPhone could optionally contribute pelvis motion or camera pose.

The progression might look like this:

Phase one: Fitness+ intelligence

Known exercise and interval
Watch based rep counting
Automatic set timing
AirPods posture confirmation
Live tempo and range consistency

Phase two: Structured open gym workouts

User selected routines
Automatic set detection
Suggested exercise corrections
Remembered resistance
Training volume and effort summaries

Phase three: Freeform recognition

Automatic exercise classification
Personalized movement calibration
Confidence aware confirmations
Pocket and camera modes for iPhone

Phase four: Connected strength equipment

GymKit resistance and equipment identity
Machine configuration
Cable or bar velocity
Standardized HealthKit set and rep record

Straight Leg Deadlifts with about a buck'80 in plates is no joke

Smartwatches already count repetitions. AirPods based apps already estimate strength movement. WHOOP models muscular load. Tonal measures resistance and cable displacement. Tempo uses iPhone computer vision. Google has patented earbud + watch exercise recognition. Apple has patented a wider system involving computer vision, smartwatch motion, automatic rep counting and equipment identification.

Apple owns the Watch, AirPods, iPhone, Fitness+, Workout, HealthKit and GymKit. It also controls the privacy, synchronization and on device processing layers required to unify exercise recognition, distributed sensing, equipment telemetry and physiological recovery into a single first party platform.

This could transform Traditional Strength Training from a timer with a heartrate graph into a computational record of what the athlete actually did and give strength training the same depth of measurement Apple already brings to running and cycling.

🤘Robin

All writing · Original LinkedIn edition

Kinematics Lab Part II: You Don't Need Another...

Robin Winters — 2026-07-30

Kinematics Lab Part II: You Don't Need Another...

By Robin Winters

First published July 30, 2026 on LinkedIn. Republished October 2, 2026 with original wording, images and captions. Technical observations and opinions retain their original context.

FitTech Has a Junk Drawer Problem

As stated in the previous article, the premise behind my Kinematics project is proving that Apple may already have enough sensors in the right places to make strength training more legible.

In most cases the answer to the question of how best to automagically capture and log Traditional Strength Training data is not another device, but rather better coordination between the devices already in the room. For millions of people that means Apple Watch, AirPods, and iPhone.

Treadmills and ellipticals, like most cardio training, generate machine readable workouts because the movement is repetitive and/or already instrumented. Strength Training is...messier. A set of alternating dumbbell curls may contain 16 separate arm events, only half of which happen on the arm/wrist wearing a device capable of capturing fitness data. A squat may be dominated by hips, knees, glute position, and load, while the wrist contributes stability but are otherwise static and nearly invisible to a fitness app. In Apple Fitness+ most of this mechanical work collapses into Traditional Strength Training, but users/athletes still have to manually log sets, reps and gauge difficulty based on how sweaty they are at the end of a workout.

I think I can build something better that doesn't require buying any new equipment or FitTech gadgetry.

Waves, y'all. Waves.

The Useful Sets & The Not So Useful Sets

My first useful physical capture was a normal set of dumbbell lateral raises where the exported session contained 3,737 sensor samples from the cross device application I've built for utilizing the metrics captured from primarily the gyroscopes/motion sensing on Apple Watch, iPhone, and AirPods.

Apple Watch: 916 samples
AirPods: 1,406 samples
iPhone: 1,415 samples

The Watch stream was complete and close to the requested 50 Hz capture rate. A deterministic Apple Watch first detector found reps from the dominant wrist rotation signal pretty easily. The interesting bit was that the AirPods trace overlapped with the Watch trace, which is what I was aiming for. The zero lag correlation was roughly 0.58, and the best alignment improved slightly when AirPods lagged by about 80 milliseconds.

The next set of tests were alternating dumbbell curls that broke the demo. It should have been the better demo, however the alternating curls expose the weakness of a single wrist sensor. If the watch is on the left wrist it obviously observes the left arm better than the right. The other arm has to be inferred through rhythm, torso response, AirPods motion, timing, or user correction, which is what I'm trying to avoid. The exported file contained 4,752 samples overall, but only 239 Watch samples. The sequence range suggested thousands of missing positions. In practical terms, Watch capture was around 8% complete. Before the prototype could become smarter it had to become better about capture quality.

So the Apple Watch capture path was rebuilt around batch acknowledgement. Watch motion samples are buffered into batches. Each batch receives a stable ID, the iPhone acknowledges receipt and the Apple Watch keeps pending batches until they are acknowledged. If live delivery fails, the Watch queues a recovery transfer. If the same batch arrives twice, the iPhone deduplicates it. The CSV export, that I'm pulling off the iPhone app after each set to avoid cross exercise data contamination, now includes integrity rows for each sensor source:

quality
coverage
expected sample count
received sample count
missing sample count
duplicate or disordered sample count
maximum device time gap

The Kitchen Junk Drawer. Everyone has one.

The Market & AI

There are already quite a number of rep counters out there. Add to that connected strength machines, camera based systems, and Apple Watch apps that attempt automatic exercise recognition. Garmin is also in on it and has offered watch strength rep counting for years, with the predictable limitations of a single wrist worn sensor. Similar products attack the problem through proprietary hardware that ultimately end up adding to the mountain of e-waste from FitTech trying to reinvent the wheel every fiscal quarter. My version is anti-gadget and built around the premise that Fitness+ has an orchestration advantage. The workout UI and health database plus developer frameworks, now including Apple Intelligence on capable devices, can turn raw workout data into useful summaries that can aggregate even imperfect readings and present the result in the same visual language users already understand.

The biggest product issue, imo, is adoption. Users and consumers loathe shoehorning hardware and software alike into their already functioning systems. To make a product that easily integrates into preexisting structures is the most difficult part of the development process, and adding features also adds complexity. Most people want less complexity and more reliability. Reliability, specifically, is one of the biggest challenges facing tech at the moment. AI's Achilles’ Heel is a combination of cost and reliability both of which seem to be moving in the right direction with Apple Intelligence.

How's that for a segue?

Apple Intelligence & Foundation Models Framework adds new, powerful on device intelligence for interpreting data, however, throwing IMU streams directly into a language model would be brittle and would blur the line between measurement and explanation. There's a balance that needs to be struck between straight up Math and the subjective narratives surrounding the interpretation of data sets from health and fitness readings and/or user outcomes.

A better architecture is layered:

collect motion and workout context
score data integrity
segment sets
detect candidate reps
fuse Watch, AirPods, iPhone, and equipment evidence
generate a structured set summary
use Apple Intelligence to explain what happened
rinse and repeat

The model should receive structured facts from signal processing and statistical models, then translate those facts into useful coaching language where Apple Intelligence acts as an interpreter of sorts.

The iPhone and Apple Watch apps build and the app can collect Watch/AirPods/iPhone sensor data. It can start a traditional strength training workout session on Apple Watch and then export CSV files with raw samples, events, and sensor integrity. It doesn't provide live rep counting in the UI yet and has a rough time attributing alternating curls by side. It's also a bit off when trying to resample all the streams onto a shared 50 Hz timeline. It can generate post set Foundation Model summaries, but can't write rich set level semantics into HealthKit...yet.

What's Next?

Ultimately I want to do away with manually inputting exercise data altogether and dissuade users from new devices whose main job is to compensate for the fact that the Apple devices already present are not being coordinated well enough for logging weight lifting and strength training, all while being local on device and available offline. That's not to say that all device innovation is a waste, but in this one niche area of health and fitness we're sorely lacking the modern data logging tools available to other athletics.

If developers, namely me, want Fitness+, HealthKit, GymKit, AirPods, Apple Watch, and Apple Intelligence to feel like one fitness platform rather than several adjacent products, the weight room is the obvious place to prove it because lifting is still mostly invisible.

The next great strength training device might not be a single device at all, but rather Apple Watch, AirPods, and iPhone acting in concert in the same workout.

Okay, back to the gym.

🤘Robin

All writing · Original LinkedIn edition

Fitness event feeds: explicit dates, stable identity and visible conflicts

Robin Winters — 2026-10-02

Fitness event feeds: explicit dates, stable identity and visible conflicts

Robin Winters · October 2, 2026 · robin.ac

A map can look polished while the events behind it are ambiguous. Two feeds may repeat a record, supply different start times for the same event, or omit the timezone. Guessing produces a neat interface at the cost of hiding uncertainty. A better starting point is a small contract that makes each decision inspectable.

This article accompanies a standalone Swift teaching package, prepared with coding-assistant support. Its fixtures are synthetic. It is separate from private ShowFlex code and does not claim a customer deployment, an implemented product integration or measured performance improvements.

Start with the fields you can actually defend

The example accepts a provider ID, a feed ID, a title, a start timestamp, an optional end timestamp and an HTTPS source URL. The combination of feed ID and provider ID becomes the stable identity. Titles are display text; a matching title does not justify merging records. Different feeds can describe related real-world events, but cross-feed entity resolution requires evidence that this package deliberately does not invent.

The package normalizes the feed slug to lowercase and trims provider IDs while preserving their case. Neither ID may contain the colon used to join them. That keeps feed-a:event-17 unambiguous within the stated contract. A real service would also need to establish whether each provider guarantees stable IDs across updates and deletions.

Timezone ambiguity is a data state

2027-03-14T10:00:00-07:00 has an explicit offset and can be represented as 2027-03-14T17:00:00Z. A timestamp without an offset does not establish that instant. The example rejects it instead of using the machine's local timezone. It also rejects invalid calendar dates rather than allowing them to roll into a different day.

An unknown end time remains absent. Adding a guessed two-hour duration would manufacture information. If an end is supplied, it must be later than the start. Date-only events, recurring schedules, named timezones and fractional seconds need their own policies; unsupported timestamp forms are rejected here.

UTC output makes the normalization reproducible. A calendar or mobile interface would still need a deliberate display-timezone policy. That interface work is outside this package's execution evidence.

A duplicate and a conflict deserve different treatment

Two valid rows with the same identity and the same normalized payload are retransmissions. Keep one event and issue a duplicate receipt for the other row. Equivalent explicit-offset timestamps and collapsed title whitespace can produce an identical normalized payload.

Two different valid payloads with the same identity are a conflict. The example removes that event from accepted output and marks every related valid row as conflicted, including a duplicate already seen earlier. No row wins simply because it arrived first. Permuting the input order therefore cannot choose a different accepted version of that conflicting identity.

This is a teaching policy, not the only useful production policy. A provider revision number, authenticated correction or trusted snapshot might establish a winner. Without that evidence, a quarantine is easier to explain than a silent overwrite.

Return a receipt for every row

The output includes sorted accepted events and one receipt per input row: accepted, duplicate, conflict or rejected. Each receipt records the input index and a reason. A rejected row can therefore be traced to the input rather than disappearing into an apparently successful empty array.

The supplied five-row fixture produces one accepted event, one duplicate receipt, two conflict receipts and one invalid-date rejection. Invalid JSON exits with status 1 and produces no successful JSON report. That distinction matters when a command-line tool is used in a larger workflow: malformed input and a valid feed containing no accepted events are different outcomes.

Keep provenance narrower than proof

The source URL is retained as a retrieval pointer. The package rejects non-HTTPS URLs, embedded credentials and fragments. It does not fetch those URLs, authenticate a provider or establish that a claimed event exists. Every fixture URL uses the reserved example.org domain.

Storing provenance is a useful first step toward investigating a record. It should not be described as verification of that record. A production ingestion system needs provider authorization, versioned snapshots, update and deletion rules, observability and retry behavior alongside its field validation.

Evidence a reviewer can inspect

On October 2, 2026, the package passed 12 Swift Testing checks on macOS with Swift 6.4. The checks cover timezone equivalence, retransmissions, conflict propagation and ordering, source-scoped identity, malformed dates, missing offsets, end-time rules, URL restrictions, unknown ends and sorted output. The command-line fixture and malformed-JSON failure path were also exercised. The repository includes fixtures and verification details.

These results describe this educational package. They do not establish iPhone-device execution, Linux execution, an App Store release or an improvement to an existing product. The value of the example is that its contracts and failure decisions are small enough to inspect and reproduce.

Professional work and evidence · Full writing index · Source package

What if Myspace Had It Right?

Robin Winters — 2026-04-01

What if Myspace Had It Right?

By Robin Winters

First published April 1, 2026 on LinkedIn. Republished October 2, 2026 with original wording, images and captions. Technical observations and opinions retain their original context.

Tom. Friend to all.

Let's talk about feeds.

How sticky are feeds? How personalized are feeds? How fast can feeds learn you? How well can feeds keep serving you content you didn’t ask for?

In terms of the Enshittification of UX across pretty much all modern social media maybe Feeds in general are part of the problem. But what would Social Media look like without a Feed? How would that even work?

Take a hike, Friendster, we're bringing it back to the real OG; Myspace.

To preface this, Myspace was far from perfect. It was ugly, launched the proliferation of up angle selfies, and fell out of vogue basically overnight.

However, Myspace centered UX around the User Profile instead of an Algorithmic Feed.

When Feeds became the center of Social Media UX user profiles became secondary and everything started bending toward whatever content keeps attention the longest and/or triggers the most repeat engagement (read as enragement). Once you do that, you start drifting toward rage bait and Boomer meme slop.

Shrimp Jesus, people. Shrimp Jesus.

I think Myspace, weirdly enough, had it right.

When you landed on someone’s page, you were entering their space. Their aesthetic, their vibe, their weird HTML decisions. It was messy, sometimes hideous, but it felt like a person.

That is wildly different from the experience most platforms train people into now, where interactions get routed through an opaque engagement engine.

That idea has been on my mind while building the social layer for ShowFlex.

ShowFlex isn't trying to become another generic social app with a bodybuilding skin wrapped around it - which sounds way grosser than I intended it to, but I'm leaving it in.

I’m more interested in building a social layer that feels tied to the person and their place inside the sport.

I don't want the center of gravity to be some endless feed, shoveling algorithmic sludge at people because being "Big mad" converts. I want the center of gravity to be the profile, which in a sport like bodybuilding makes total sense. People care what your presence in the sport looks like, all of which being inherently profile native.

Avril Lavigne vibes. So complicated. So frustrated

A profile centric social layer also has a healthier shape to it.

It gives users somewhere to build from. It makes social interaction more legible and creates a stronger sense of place. It can make discovery feel more intentional instead of just reactive, and most importantly it reduces the amount of power handed to a hidden ranking engine that optimizes for emotional volatility.

So when I say I'm building a social media layer more like Myspace, I don't mean I'm are trying to cosplay 2006 internet aesthetics for nostalgia points - though I did find out Neo Y2K Futurism Aesthetic is making a come back. It's Rad. Look it up.

What I mean is that I'm taking seriously the idea that social products work better when people feel like they have a space and a visible relationship to a community, not just a stream.

So, maybe Myspace had something right. Not everything, but enough that it is worth revisiting the good parts and leaving the rest in the glitter gif covered tomb where it belongs.

Cue the Ooga chaka baby. Everything old is new again.

Build accordingly, and as always:

May the Force be with you.

🤘 Robin Winters

All writing · Original LinkedIn edition