The Kotlin SDK provides Jetpack Compose components and API helpers for integrating Bible content into Android applications. Complete the Quick Start before using these examples.
Filter the Bible versions you offer
By default, every version picker in the SDK — in BibleCard and in BibleReader — offers Bible
versions in every available language. Two optional configure parameters narrow that list.
Pass permittedLanguageTags to restrict the picker to a set of languages. For example, to make
only English versions available:
Code
Tags follow BCP 47 (for example "en" for English,
"es" for Spanish). When the resulting list contains versions in only one language, the language
button in the version picker is hidden automatically.
Pass permittedVersionIds to restrict the picker to specific Bible versions:
Code
IDs are the YouVersion Bible version IDs (for example 111 for NIV, 1588 for AMP). The two
filters combine — a version must satisfy both to be shown.
Display Content with BibleCard
The SDK ships with Jetpack Compose components, including BibleCard, which renders a passage given its reference.
Provide a BibleReference describing the version, book, and verse range you want to display, and optionally adjust the font size.
Code
The card will fetch and format the passage automatically.
Let users switch versions with the version picker
Pass showVersionPicker = true to render a version-picking button in the card's header.
Tapping it opens a bottom sheet where the user can pick a different Bible version, and the
card re-renders the passage in the selected version automatically.
Code
Provide an optional onVersionChange lambda if you want to react to the user's selection —
for example, to persist their preferred version so it can be used as the default the next
time the card is shown.
Code
Display Content with BibleText
Use BibleText when you want inline scripture rendering in your own layouts.
Unlike BibleCard this is "merely" the nicely formatted text of the Bible passage:
it doesn't include elements to show the verse reference,
doesn't show the Bible version's name or its copyright information - you need to provide
those separately. See Copyright & Attribution
for a complete example that keeps the passage and its version metadata in sync.
You can pass a single verse, a verse range, or a full chapter reference.
Single verse
Code
Verse range
Code
Full chapter
Code
For longer passages, wrap BibleText in a verticalScroll.
When the user is signed in and has granted the highlights permission, BibleText also renders
their YouVersion highlights behind the verse text, so a custom reading UI stays in sync with
BibleReader. See Highlights.
Embed a Full Reader with BibleReader
BibleReader displays a complete Bible reading experience, very similar to the YouVersion Bible
app, ready to be added as a tab in your app. It lives in the platform-reader module.
Code
The sign-in prompt the reader presents to a signed-out user names your app and shows your own reason for asking. Both come from configuration:
Code
Both parameters are optional. signInPromptMessage supports **bold** markdown. Leave appName out
and the prompt names your app by its launcher label — set it when that label is not the name you want a
reader to see before granting account access.
Earlier versions took this copy as the BibleReader parameters appName and appSignInMessage.
That overload is deprecated as of SDK version 1.8.0 but still works — it writes both values into
configuration for you — so existing code needs no change. It will be removed in the next major
version, so configure them instead.
Open to a specific passage
Pass a bibleReference to choose where the reader opens:
Code
Offer your own fonts and a bottom bar
Pass a fontDefinitionProvider to add your own fonts to the reader's font settings sheet, and a
bottomBar composable to render your own content beneath the reader — a tab bar, for example.
Code
Disabling Sign-In
By default, a signed-out user who taps a verse is prompted to sign in with YouVersion. To suppress
all SDK-provided sign-in UI, including that prompt and the header menu's sign-in option, set
isSignInEnabled to false during configuration:
Code
When sign-in is disabled, the reader hides the highlight colors rather than offering a control that could never work.
Implement Sign In with YouVersion
If your app needs authenticated user data, use SignInWithYouVersionButton.
1. Configure the redirect in AndroidManifest.xml
Code
2. Extend SignInWithYouVersionActivity
Code
3. Add SignInWithYouVersionButton to your UI
Code
Highlights
Highlights belong to the user's YouVersion account, not to your app. A highlight created in your app appears in the YouVersion Bible app and in any other app the user has granted access to, and highlights the user already made elsewhere appear in yours.
BibleReader provides the full experience with no extra work: tapping a verse opens the verse
action sheet with a color picker, choosing a color highlights the selected verses, and choosing the
color a verse already has removes the highlight. On dark reader themes the colors are dimmed
automatically so the verse text stays readable. BibleText renders the same highlights, so a
custom reading UI built on platform-ui stays in sync with the reader.
Highlights require SDK version 1.8.0 or later. On earlier versions
SignInWithYouVersionPermission.HIGHLIGHTS does not exist and the highlights API cannot be called
successfully.
Highlights are layered across the three modules, so you only need the ones your integration uses:
| Module | What it adds |
|---|---|
platform-core | The highlights API, the HIGHLIGHTS permission, and the local cache. Enough on its own to read and write highlights. |
platform-ui | Highlight rendering behind verse text in BibleText, plus the helpers for requesting the permission. |
platform-reader | The verse action sheet color picker, the color palette, and dark-theme dimming. |
Highlight permissions
Reading and writing highlights requires the user to be signed in and to have granted
SignInWithYouVersionPermission.HIGHLIGHTS. There is no anonymous or app-local highlight, so the
permission is only ever obtained through YouVersion sign-in — either bundled into the sign-in
request, or added afterwards for a user who is already signed in.
BibleReader asks for it at the moment it is needed, taking one of those two routes:
- A signed-out user is offered sign-in, with the highlights permission included in the requested permissions. The grant rides along with the sign-in.
- A signed-in user who has not granted it yet is shown a confirmation dialog and then the YouVersion permission page. This is the data exchange flow, and it exists so the user does not have to sign in again just to grant one more permission.
Both routes come back through the youversionauth://callback redirect used by sign-in — either as
an activity result when the SDK opened the permission page in an Auth Tab, or as a deep link into
your SignInWithYouVersionActivity. Either way, highlights only work end to end once your app has
completed the Sign In setup: the manifest intent filter and
a main activity extending SignInWithYouVersionActivity. Without that setup the grant never
reaches the SDK and highlights stay unavailable.
To check whether the permission has been granted:
Code
Requesting the permission without the reader
If you render highlights with BibleText but do not embed BibleReader, nothing in your app ever
asks for the grant — the verse action sheet is the only built-in prompt. Without a request of your
own, the user simply never sees their highlights. The same applies to users who signed in before
you added highlights: they have no HIGHLIGHTS grant, and nothing will ask them for one.
For a user who is already signed in, request it from Compose with rememberDataExchange. This
is a top-up rather than an alternative to signing in — a signed-out user needs
SignInWithYouVersionPermission.HIGHLIGHTS included in the sign-in request instead.
Code
Outside Compose, use DataExchangeHandler(activityResultRegistry).requestDataExchange(...)
directly. Either way the granted permission is persisted for you before the call returns, so a
later YouVersionApi.hasPermission(...) reflects it without any extra work. A BibleText already
on screen picks up the new grant and loads the user's highlights without being recreated.
Data exchange only works for a user who is already signed in — it mints its token from the
existing access token. For a signed-out user nothing is presented at all (the result status is
DataExchangeStatus.NotStarted); request SignInWithYouVersionPermission.HIGHLIGHTS as part of
sign-in instead. rememberDataExchange and DataExchangeHandler live in platform-ui.
Highlights API
Apps using only platform-core can read and write highlights directly through
YouVersionApi.highlights. All four calls are suspend functions and require the signed-in user to
have granted the highlights permission.
Code
Note that passageId is a chapter for the read call ("JHN.3") but a single verse for the write
calls ("JHN.3.16").
Colors are hex strings without a leading #. The palette the reader offers is fffe00 (yellow),
5dff79 (green), 00d6ff (cyan), ffc66f (orange), and ff95ef (pink), matching the Swift SDK.
rememberDataExchange and DataExchangeHandler live in platform-ui, so an app on
platform-core alone cannot use them. Ask for the grant by including highlights in the
requested_permissions of your sign-in request instead.
Error handling
The read and write calls report failure differently, so handle both:
- All four calls throw
YouVersionNetworkExceptionwith reasonNOT_PERMITTEDwhen the user has not granted highlights access. This applies to the whole account rather than to the requested chapter, and the request will not succeed on retry. - The read call also throws
YouVersionNetworkExceptionwith reasonMISSING_AUTHENTICATIONwhen the request was not authenticated, which a sign-in or token refresh may resolve. A failure is reported rather than an empty chapter so that callers caching the result do not mistake it for the server reporting that the chapter holds no highlights. - The create, update, and delete calls each return a
Boolean. Afalsereturn — for an unauthenticated request, for example — means the write did not happen, so check the result and don't rely ontry/catchalone.
To call the same endpoints outside the SDK, see the highlights REST API reference.
Display Verse of the Day
Use the built-in Verse of the Day components:
Code
Or fetch Verse of the Day data for custom UI:
Code
Example code
See the SampleApp project in the Examples folder to see the above code in action!