Shared Swift code needs an explicit integer-width contract
Audit Int width at the iOS and wasm32 boundary before reusing Swift algorithms, and choose wider storage only when the data contract actually requires it.
By 
Paul. Languages and frameworks
Sharing source code preserves an algorithm only if its representations preserve the values the algorithm needs. An integer type that was wide enough on one target can become a hidden platform dependency on another. Before treating shared Swift packages as portable behavior, make the width of their meaningful values explicit at the point where data crosses a platform boundary.
This is a narrower and more useful requirement than replacing every integer with a wider type. Some integers describe local collection positions. Others carry values that must survive storage, transfer and use on several targets. The right choice follows the value's contract. A type name that compiles in both places is not enough evidence that the contract remains intact.
The portability account predates its publication
In the Goodnotes engineering account published on 1 June 2026, the team describes a web effort begun in 2021 and already operating in production. It is an account of earlier work, rather than a June product launch. Its relevant observation is specific: Int is 32 bits on wasm32, and assumptions about 64-bit values required explicit Int64 in some code.
The May Swift roundup, published on 3 June, subsequently links that account. The month in the digest's title describes its topics; it does not move publication into May. Nor does a digest that mixes releases and accepted proposals establish that every discussed language feature shipped in a stable toolchain at that point.
The lesson here does not depend on adopting the account's performance, binary-size or code-sharing figures. Those are the author's reports about Goodnotes. They are not measurements of another application, and they cannot establish a business case for an unrelated rewrite. The useful starting point is the representation mismatch that a team can inspect in its own design.
Start with the value's meaning
Consider an illustrative shared document format carrying an integer identifier. If the format permits values beyond a signed 32-bit range, reading that field into a platform-sized integer creates an obligation the narrower target cannot fulfill. The algorithm may be unchanged while its input is no longer representable. The problem occurs before any argument about whether the algorithm itself is portable.
A different field may contain a small, bounded count. If its maximum is part of the domain contract and every intermediate calculation remains within the supported range, wider storage may offer no correctness benefit. These two fields should not acquire the same policy merely because both happened to use Int in an iOS implementation.
For each value that crosses the boundary, establish its signedness, permitted range and units. A duration expressed in a finer unit can grow much faster than the same duration expressed in a coarser one. A multiplication used to calculate an allocation can exceed the final count's range. The analysis must cover intermediate values as well as stored inputs and final outputs.
That is a design inspection, not a claim that a particular application currently fails. The example shows what evidence would be needed: the field's permitted values, the target representation and the operations performed between reading and writing it. Without those facts, prescribing a type change would be guesswork.
Conversion belongs at a visible boundary
A useful boundary separates domain values from platform-specific indexing. A shared model can preserve a value in the representation its contract requires, while an adapter decides whether that value can be used as a local index or count. The adapter needs an explicit response when conversion is impossible. Silent loss of information would change the input while pretending that the same operation continues.
The response depends on the product. An invalid external value may need rejection; a valid but unsupported document may need a clear explanation. Narrowing a value just to fit an existing parameter can turn either case into misleading behavior. Decide which condition the application has encountered before deciding what the user should see.
The boundary also makes maintenance more concrete. A reviewer can inspect the conversion rule without reinterpreting every arithmetic operation in the shared package. Future contributors can distinguish a fixed-width domain value from a target-sized convenience. That clarity matters even if the code continues to run on only one target for a while.
Wider storage has a scope
The strongest counterargument is straightforward: much application data is already bounded comfortably within 32 bits. Changing every integer can spread conversions through collection APIs and make local code harder to follow. It may solve no observed representation problem. Retaining a platform-sized integer can be reasonable where its target-dependent capacity is part of the intended use.
The conclusion is therefore conditional. Shared algorithms need an audit of their representation assumptions, not a universal Int64 prescription. A successful portability decision can leave many fields unchanged while assigning explicit width to the few whose values demand it. It can also identify platform-specific behavior that should stay behind an adapter instead of being forced into the shared core.
If you are planning custom software development across mobile and web targets, ask for the data contract alongside the reuse plan. Establish which values must survive unchanged and where conversions can fail. That gives code reuse a reviewable boundary before a shared package becomes a promise of identical behavior.