Four Years Owning all Mobile for a Fortune 500 Tax Platform

Client: H&R Block

Engagement: 4+ years, full ownership of iOS and Android applications

Ownership: Product strategy, design, architecture, engineering, and QA across all mobile apps

Stack: Native iOS (Objective-C), Native Android, RTMPS, SAML, custom tooling

Trusted Technical Partner

H&R Block’s mobile products sit at the intersection of tax law, financial data, regulatory compliance, and a fixed seasonal deadline. Every year, the apps had to ship — correct, secure, current with that year’s tax code — before filing season opened. There was no soft launch. The apps worked on day one, or they didn’t.

For over four years, BiTE owned all mobile applications end-to-end. Product strategy, design, architecture, engineering, QA — across both iOS and Android. Our teams solved problems that required deep knowledge of mobile platforms and security infrastructure, and the judgment to make decisions that protected the client — sometimes before the client even knew they needed protection.

“For over four years, H&R Block trusted BiTE to own mobile end-to-end—strategy, architecture, engineering, and QA—across iOS and Android.”

Derek Swords

Director Of Product Development

Global User Authentication: SAML Without the Browser

The Problem

H&R Block’s authentication infrastructure was built on SAML — an enterprise SSO standard designed for web browsers. SAML’s flow is fundamentally browser-centric: redirect the user to an identity provider, authenticate, and redirect back with a signed assertion. The protocol assumes HTTP redirects, POST bindings, and a browser that maintains cookie state across the chain.

Native mobile applications are not browsers. The common approach is to embed a web view and route the user through the redirect flow. This works, but it creates problems that compound across a portfolio of applications — and H&R Block had multiple mobile apps, with plans to add more.

A web view is a visible seam in the user experience: the user leaves the native interface, enters what is clearly a web page rendered inside the app, authenticates, and returns. Each app implementing its own wrapper would produce inconsistent loading behavior, error handling, and session edge cases — at the exact moment users are entrusting the app with their credentials. A web view also introduces JavaScript, unnecessarily widening the attack surface. And perhaps most importantly, separate implementations in each app meant separate surfaces to audit, validate, and fix. A shared native library meant a single authentication implementation to harden and submit for security review — not a scattered collection of web view wrappers that each required independent verification.

Every year the apps shipped before tax season—correct, secure, and current with the year’s tax code. There was no soft launch.

– derek swords

What We Built

GUA — Global User Authentication — was a standalone native library for iOS and Android that implemented the SAML handshake natively. No web views. No browser redirects. GUA constructed the authentication requests, communicated directly with H&R Block’s identity provider, parsed the SAML assertions, and returned an authenticated session.

Beyond the handshake, GUA managed the full session lifecycle: token persistence across app launches, expiration tracking, silent refresh when valid, re-authentication prompts when not. The consuming application never touched SAML. It called GUA, got a session, and used it. When the session expired, GUA handled it.

The library was a drop-in dependency. Any H&R Block mobile application could integrate GUA and immediately inherit the complete authentication flow and its security properties. The boundary was explicit: applications handled their features and API surfaces; GUA handled identity. When H&R Block’s security team updated their identity provider, the change was absorbed by GUA once and propagated to every app.

Because of the data sensitivity—this was the authentication gateway for millions of users’ tax information—GUA underwent two independent security audits: H&R Block’s internal IT team and its external security and compliance vendor. Both performed exhaustive code reviews of the SAML implementation, token handling, and on-device storage. Both passed without material findings.

Secure Video Conferencing:
Speaking Flash Natively on iOS

The Problem

BlockLive was H&R Block’s initiative to bring the full in-office experience to mobile — real-time video conferencing with tax advisors, document sharing, and payments. The problem was that H&R Block had built their entire video infrastructure on Adobe Flash. Flash protocols were the transport layer. Flash clients were the only clients.

iOS did not run Flash. It never would. If the mobile apps were going to participate in BlockLive sessions, they needed to speak to Flash media servers without being Flash.

The First Approach — and Why We Abandoned It

We initially targeted RTP/RTSP—the open-standard stack for real-time media transport. H&R Block’s media servers claimed to support RTP alongside their Flash infrastructure, and we built a full native implementation: encoding, packetization, session negotiation, media delivery. It connected. It worked.

We then investigated the server’s transport security and identified a subtle issue. H&R Block’s media servers supported RTP only over unencrypted HTTP. They did not support RTSP’s secure transport layer. Every video session—customers discussing Social Security numbers, W-2 details, and bank account information—would traverse the network in cleartext. This was simply a non-starter for an application that carried sensitive financial data over an unencrypted channel. We discarded the working implementation and started over.

BiTE stabilized failure-prone areas left by other vendors, coordinated cleanly with our API organization, and shipped on fixed deadlines.

– derek swords

The Harder Path

The only remaining option was RTMPS — the secure variant of Adobe’s proprietary Real-time Messaging Protocol. RTMPS carried media over TLS, solving the encryption requirement. But it was Flash’s protocol, designed for Flash clients. There was no native iOS implementation. Adobe had published partial documentation, but it was internal reference material for Flash-to-Flash communication, not an interoperability guide.

We pieced together the available documentation and reverse-engineered the rest — the handshake sequence, the chunk stream format, AMF-encoded command messages, and the specific session behaviors H&R Block’s servers expected. The result was a native iOS video stack that spoke RTMPS fluently. The Flash servers had no idea they were talking to an iPad. From their perspective, the client was another Flash endpoint, sending and receiving video over an encrypted channel as expected.

The combination of constraints made this work significant: a seasonal deadline that could not be moved, a working implementation discarded on principle, and a replacement protocol with incomplete documentation and no native mobile support. Solving any one of these is difficult. Solving all three simultaneously — and shipping on time for tax season — required engineers who understood protocol stacks, security implications, and the business consequences of getting either one wrong.

Catching a GPL Violation Before It Shipped

Not every critical contribution is a feature. Sometimes, the most important thing an engineering team does is notice a problem no one was looking for.

During development, we identified that a third-party library from another H&R Block vendor contained GPL-licensed code. The library had a build configuration that, depending on iOS compilation settings, would statically link GPL components into the final binary.

GPL’s copyleft provision is unambiguous: if GPL code is statically linked into a binary, the entire work must be distributed under GPL terms. For H&R Block, this would have meant open-sourcing the entire mobile codebase—and potentially server-side code—as a condition of distribution. For a publicly traded financial services company, this would have created significant legal and business exposure.

The issue was a build configuration detail—a flag that determines whether a compiled dependency includes GPL code in its output. The kind of thing that is invisible unless you understand how native build toolchains resolve dependencies, how static linking works at the binary level, and what the licensing implications are under copyleft.

We flagged it before the application shipped. H&R Block addressed the vendor’s configuration, removed the GPL dependency, and no code was released under a copyleft license. The issue was resolved because our engineers understood the full artifact chain—the application code, the build system, all dependencies, and the legal implications of what ends up in the final binary.

BiteWriter and BiteLingual: Solving Copy and Translation Architecturally

The Problem

When we took over the H&R Block mobile apps, every user-facing string was hardcoded in source code. Every label, disclaimer, tax term, and piece of instructional text. In a financial application where legal and compliance teams review every word, this meant every copy change — no matter how small — required a code change, a build, and a release cycle.

The workflow: stakeholders received screenshots, marked them up, and returned them to engineering. Engineers found the hardcoded strings, made edits, rebuilt, and sent new screenshots. Each cycle took days. For an application with hundreds of screens, a tax glossary, Q&A content, legal disclaimers, and copy that changed every tax year, this was unsustainable.

What We Built

We built BiteWriter, a cloud-based copy management system that replaced every hardcoded string with a key-value lookup. Copy lived in BiteWriter — not in the source code. Each build pulled the current copy at compile time. Stakeholders edited text directly in a web interface without engineering involvement. The review cycle collapsed from days to minutes.

The deeper value was architectural. By externalizing copy into a system with a well-defined interface, we decoupled a concern that touched every screen from the application code. The app resolved keys to strings. BiteWriter determined what those strings said. Neither needed to know the other’s internals.

Once copy was externalized and keyed, translation became a configuration change rather than a project. We built BiteLingual as a language layer on top of BiteWriter — translators worked in the same cloud interface, adding localized variants for each key. The apps already resolved keys to strings; BiteLingual added a language dimension to that resolution.

To prove the architecture, we translated the entire H&R Block application — iOS and Android, every screen, hundreds of tax terms, legal copy, and Q&A content — into Spanish and had it ready to ship in four days. Not a subset. The full application on both platforms.

Four days were possible because the hard problem — externalizing copy management into a system that treated language as data rather than code — was already solved. Adding Spanish was additive. No source changes, no per-language builds, no manual screen-by-screen review. The architecture was designed so that the shape of the problem was solved once, and specific instances of it were now merely configuration.

What Four Years Demonstrate

Each of these problems required a different kind of depth. GUA was systems integration—making a web-native authentication standard work natively on mobile and packaging it so the problem remained solved across every application. The RTMPS work was protocol engineering under deadline pressure, with the judgment to discard a working solution on a security principle. The GPL catch was the kind of vigilance that only comes from engineers who understand the full dependency and build chain. BiteWriter and BiteLingual were architectural — identifying a cross-cutting concern, building the right abstraction, and proving it held when extended to a problem the client hadn’t yet asked us to solve.

These were not isolated projects staffed for a specific scope. They emerged over the course of a long engagement with a stable, senior team that had the depth to recognize problems, the authority to act on them, and the trust earned by delivering — every tax season, on time, passing independent security audits, and handling sensitive financial data for millions of users.