Library App Challenges: The Catalog Is Just the Tip of the Iceberg
Integrating a library mobile app with existing infrastructure is a quiet nightmare for many teams. It seems like just a book catalog and offline book search, but reality is: MARC21, Z39.50, OPDS integration with invalid XML, or even IRBIS-64 with a socket-based API. With 5+ years of experience and 50+ successful projects, we have developed an approach that prevents getting stuck at the data connection stage, saving up to 30% of the budget. For example, a basic library app starts at $8,000, while a full-featured solution with offline mode and scanner is from $15,000. Average project cost ranges from $8,000 to $25,000.
Why Is Integration with Library Systems a Challenge?
Most libraries use standardized data formats (MARC21, OPDS, Z39.50), but not all provide a modern REST API. For example, IRBIS-64 often works via TCP sockets — direct connection from a mobile device is impossible; a server adapter is needed. Even OPDS feeds can be broken: invalid XML, missing mandatory fields. Without a detailed audit of the existing infrastructure, the project risks stalling at the data connection stage.
How We Solve Compatibility Issues
If the library uses a modern system, it likely has an OPDS feed (Open Publication Distribution System). This is an Atom/XML API for catalogs. We parse it using XMLParsing (Swift) or kotlinx.serialization with a custom XML deserializer (Android).
If OPDS is not available, we either negotiate a REST API with the IT department or build our own backend proxy on top of the existing system. Z39.50 over the internet without an intermediary from a mobile device is practically impossible — a server adapter is needed. For small libraries without an external system, we build a custom backend (Laravel/Node) with manual catalog entry via CMS.
Comparison of Integration Approaches
| System | Integration Method | Complexity | Time (weeks) |
|---|---|---|---|
| OPDS feed | Direct XML parsing | Low | 1-2 |
| REST API | Custom integration | Medium | 3-5 |
| IRBIS-64 | Server adapter + proxy | High | 6-8 |
| Z39.50 | Only through server gateway | Very High | 8-12 |
Choosing the right approach at the start saves project budget.
Local Database — The Key to Offline Work
Book catalog is cached locally: Room (Android) / Core Data (iOS). Key entities:
@Entity data class Book( @PrimaryKey val isbn: String, val title: String, val author: String, val year: Int, val genre: String, val coverUrl: String?, val availableCopies: Int, val totalCopies: Int ) @Entity data class Reservation( @PrimaryKey(autoGenerate = true) val id: Long = 0, val bookIsbn: String, val userId: String, val status: String, // ACTIVE, COMPLETED, CANCELLED val dueDate: Long ) FTS (Full-Text Search) via Room @Fts4 for searching by title and author without network requests:
@Fts4(contentEntity = Book::class) @Entity(tableName = "book_fts") data class BookFts(val title: String, val author: String) Search works instantly offline — important for reading rooms with poor WiFi. We guarantee local search is 10x faster than any network request.
Key Features and Implementation
Catalog with Filters
LazyColumn (Compose) / UICollectionView with Diffable Data Source. Filters: genre, year, availability, language. Filtering via Room queries with dynamic conditions or @Query with nullable parameters.
Personal Account and Membership
Login via library card number + password or via QR code of the card. After login — current books on hand, history, debts, reservations. Push notifications 3 days before due date (via FCM / APNs). Background sync via Background fetch and WorkManager.
Barcode / QR Scanning
Scan ISBN for quick book search — via MLKit Barcode Scanner (Android) or Vision framework (iOS). Scan library card — QR Code via the same libraries.
E-books
If the library provides electronic resources — integration with partner programs or custom EPUB/PDF reader. EPUB rendering via Readium (iOS/Android) — open standard with DRM support.
How Integration Works: Step by Step
- Analysis — audit of library system, identification of available APIs and data formats. (1-2 days)
- Design — selection of optimal integration method, app architecture design. (1-2 days)
- Implementation — development of backend proxy (if needed) and mobile client. (2-4 weeks for MVP)
- Testing — integration verification, load testing, bug fixes. (1 week)
- Deployment — release to App Store and Google Play, push certificate setup (APNs, FCM). (1 week)
Common Mistakes in Library App Development
- Ignoring offline mode. Readers are often in areas with poor internet (reading rooms, basements). Without local cache, the app becomes useless.
- Wrong integration method choice. Trying to connect to Z39.50 directly from mobile is a failure. A server gateway is needed.
- Lack of synchronization. The app must update data in the background when network appears, otherwise users see outdated information.
Feature Performance Comparison
| Feature | Offline Time | Online Time (network) |
|---|---|---|
| Search by title | < 100 ms | 300-500 ms |
| Load catalog | from cache | 2-10 s |
| Data sync | background | on schedule |
What's Included
- Analysis of existing library system and integration method selection
- OPDS parser or REST API integration
- Local catalog with FTS search
- Personal account: membership, history, reservations
- Push notifications for due dates
- ISBN/QR scanner
- Offline mode with sync
Timelines
MVP with catalog, search, and personal account: 4–6 weeks. Full-featured app with offline mode, push, scanner, and integration with existing library system: 8–12 weeks. Cost is calculated individually after API audit. Average project cost ranges from $8,000 to $25,000.
Contact us for a free consultation — get an assessment of your library system and integration recommendations. We will select the optimal implementation option.