Product Decisions This Supports
- "Save to contacts" / "Add to address book" feature scoping. This package is the plumbing behind a single, high-visibility UX moment: a user taps a button and gets a
.vcf file that populates their phone's address book. That makes it a candidate for a low-cost, high-perceived-value feature on profile pages, team directories, event attendee lists, real-estate/property listings, or digital business cards.
- Build vs. buy for a commodity capability. vCard serialization is a solved, well-specified format (RFC 6350 / vCard 3.0). Writing a correct serializer — escaping, line folding at 75 octets, charset handling, photo encoding — is genuinely fiddly and has zero differentiation value. This is a "buy" (or "adopt open source") decision almost every time; the PM conversation should be about scope of fields supported, not whether to build it.
- Roadmap prioritization for contact/export surfaces. If the roadmap already includes lead capture, CRM sync, or outbound "here's my card" flows, vCard export is a natural adjacent increment that can ship in days rather than a quarter. Conversely, if there's no contact-centric surface, this package solves a problem you don't have.
- Integration surface decision: bundle vs. underlying library. The important product insight is that this is a thin Symfony2 bundle wrapping
jeroendesloovere/vcard. The PM decision is really "do we couple to a framework-specific wrapper with a stale release cadence, or do we depend on the library directly and write ~20 lines of service wiring?" The bundle itself adds little product value beyond DI configuration.
- Format-version commitment. Deciding whether to emit vCard 3.0 (broadest device compatibility) or 4.0 (richer, but inconsistent support in older iOS/Android/Outlook) is a product decision about which devices your users actually carry — this package's era suggests 3.0-era assumptions.
- Data-exposure review. Any vCard export is an outbound data path: it defines exactly which fields (personal mobile, direct email, photo, job title) leave your system and land in someone's phone forever. That's a privacy/product governance decision this feature forces you to make explicitly.
When to Consider This Package
Consider it when all of the following hold:
- You are maintaining an existing Symfony 2.x or 3.x application where the bundle-registration conventions still work and a Composer-installed bundle is genuinely less friction than manual wiring.
- You need write-only, straightforward vCard 3.0 generation — name, org, title, phones, emails, address, URL, maybe a photo — and nothing more exotic.
- Volume and criticality are low: a download button, not a bulk export pipeline or a sync engine.
- You are comfortable that the underlying library is the real dependency and the bundle is a convenience shell you could replace in an afternoon.
Look elsewhere (or use the underlying library directly) when:
- You are on Symfony 4/5/6/7 or PHP 8+. This bundle's last release is November 2018, predating Symfony 4's flex/bundle changes and PHP 8 entirely; expect friction, and expect zero upstream support.
- You need vCard 4.0, vCard parsing/import, iCalendar/
VEVENT output, or QR-code-embedded vCards — you'll want a maintained library (brick/vcard, daverandom/vcard, or a dedicated QR/vCard combo) instead.
- Security or compliance review is in the path. Six-plus years without a release, 16 stars, and zero dependents means no maintainer community to catch escaping or injection issues; a thin, well-specified serializer is low risk, but you must accept it as unmaintained code you now own.
- You need photos at scale, non-ASCII/UTF-8 name handling, or line-folding correctness verified — validate against real devices before committing, because there's no active issue tracker momentum to lean on.
Net PM read: treat this as a reference implementation, not a dependency. The pragmatic plan is to adopt the underlying jeroendesloovere/vcard library (or a maintained alternative) directly and skip the Symfony2-era wrapper entirely.
How to Pitch It (Stakeholders)
To executives: "Adding a 'Save to contacts' button is a small, cheap, visible win — users stop re-typing our details into their phones. The code to produce the contact file is a solved problem, so we're not inventing anything; we're wiring an open-source, MIT-licensed serializer into an existing page. Cost is measured in days, not weeks, and there's no licensing or vendor lock-in."
To engineering: "This is a thin Symfony2 bundle over jeroendesloovere/vcard. The bundle is stale — last release 2018, no dependents — so the recommendation is to depend on the underlying library directly and register it as a service ourselves. That's a few lines of config, keeps us current on the serializer, and avoids adopting an unmaintained framework wrapper. We should pin the version, write our own tests against real iOS/Android/Outlook imports, and treat the output as an outbound data path that needs a quick privacy sign-off on which fields we include."
The one-line decision: low-cost, low-risk, commodity feature — adopt the library, skip the bundle, and keep the field list minimal and deliberate.